Viscosity Remembered the Password: What That Checkbox Did

That checkbox at the login prompt looks like a client preference, and on a managed machine it is often a policy decision instead. Viscosity's remember control stores the credential in the macOS Keychain when the deployment permits storage. The myth is that the checkbox is always yours to set. In practice three separate things can block it, and only one of them is about the password.

What the checkbox actually stores

Selecting the remember option asks the client to keep the value for that one connection and account. The item lands in the Keychain, and later logins reuse it through the supported prompt rather than through a hidden preference. Nothing is written into the connection file itself. That separation is also why removing the item later produces a prompt instead of a broken profile.

The saved value is an input to the authentication the server was always going to perform. It does not change what the gateway requires, does not bypass a second factor, and does not turn a one-time code into a reusable secret. What it shortens is the typing, not the policy the deployment applies to that account.

Why the control can be missing

An administrator can disable credential saving for a managed installation, and SparkLabs documents the remember control together with its Keychain behaviour in the credential-storage guide. When the checkbox is absent, it is not broken, and hunting for a preferences command that overrides it is the wrong response.

Ask the owner which supported workflow applies instead. A deployment that forbids storage usually has a reason, and the reason is often that the account is shared, the device is not trusted, or the credential is meant to expire on a schedule. Working around the setting converts an intentional control into an incident, and the incident usually arrives with somebody else's audit attached to it.

On an unmanaged installation a missing control is a support question with a version number attached. Send the installed client build and what the prompt actually shows, rather than a guess at hidden defaults.

Three prompts that are not the same prompt

A one-time code is not a password, a password is not a Keychain authorization, and a server rejection is none of the three. Mixing them up produces failures that read like wrong credentials when the real problem is a field, a dialog or a route.

The Keychain dialog is local by design. It asks whether this application may read this item on this machine, and approving it says nothing to the VPN server.

That is why denying the dialog produces a client-side failure the server never sees, while a wrong password produces a server-side rejection the client can only report. Read the dialog before answering it, and check that the requesting application is the client you expect rather than an installer or a helper process. The distinction matters most on shared machines, where the item may be reachable by more than one account.

A second factor sits outside all of this. Storing a password does not store the code, and a deployment that requires the code still requires it on every connection. Keep that step visible during testing, because a flow that silently skips it is not the flow you configured.

Recovering one credential without resetting the rest

If authentication fails after a password change, use the client's documented re-prompt and update path for that one connection rather than editing the Keychain by hand. Read the message before replacing anything, since a timeout, a certificate rejection or a missing route is not repaired by overwriting a stored password. Doing it repeatedly mostly trains you to ignore the error the client is showing. Update the affected credential, then reconnect and watch which prompt appears.

The whole-keychain reset that support forums suggest is a much larger change than the problem. One connection's stored password has nothing to do with another connection's certificate, and clearing everything turns a single stale item into an afternoon of re-enrolment.

Finish by disconnecting and reconnecting through the normal controls, confirming the intended account is used and that removing the saved item produces a prompt rather than a failure. Predictable reuse with one clear way to update or remove the credential is the outcome worth testing for.