feat: add OS keyring support for session tokens#307
Conversation
Switch the CLI manager to provide session tokens through the CODER_SESSION_TOKEN environment variable when running `coder login` instead of appending `--token <value>` to the process arguments. We’re making this change for security reasons. Command-line arguments are more likely to be exposed through process listings, shell history, CI/job logs, and command auditing, while environment variables have a smaller exposure surface on typical systems. This aligns the plugin with the Coder CLI guidance that prefers CODER_SESSION_TOKEN over `--token`.
Replace zt-exec with a small internal ProcessBuilder-based runner so subprocess failures stay under our control. We needed to remove ProcessExecutor because its exception messages include the spawned process environment. Now that CLI auth is passed through CODER_SESSION_TOKEN, failures could spill tokens into logs before our own sanitization had a chance to run. That made reliable redaction impossible/ugly at the logging layer. The new runner uses Java 21 ProcessBuilder from Kotlin, captures stdout and stderr, supports expected exit codes and stderr discard-on-success behavior, and throws project-owned process exceptions with centralized secret sanitization. This keeps process execution behavior explicit while avoiding a dependency that could format sensitive environment values into exceptions.
Pass --use-token-as-session when logging the CLI in so the CLI persists the same token the plugin already uses for REST API calls. Without this flag, a supplied token is only used to bootstrap login and the CLI mints and stores a different session token of its own. That leaves the plugin and CLI using different credentials, which makes auth state harder to reason about and prevents Toolbox from managing a single shared token consistently. Using --use-token-as-session keeps both sides on the same credential, improves consistency between REST and CLI behavior, and opens the door to revoking that shared token cleanly from Toolbox later on. Tests were updated to reflect the new login command shape.
Add a new useKeyring setting so Toolbox can let the Coder CLI persist the shared session token in the OS keyring when that storage mode is actually supported. When enabled, Toolbox stops forcing --global-config for authenticated CLI commands only if the CLI supports keyring-backed auth and the platform is macOS or Windows. That keeps REST and CLI auth on the same persisted token without changing Linux behavior, where the plugin continues to use its deployment-specific config directory.
fioan89
requested review from
EhabY,
code-asher,
jeremyruppel,
zedkipp and
zenithwolf1000
and removed request for
code-asher and
zedkipp
| } | ||
|
|
||
| private fun shouldUseKeyringAuth(feats: Features): Boolean = | ||
| context.settingsStore.useKeyring && feats.keyringAuth && supportsKeyringStorage(currentOs) |
There was a problem hiding this comment.
Is there any visibility for users that enable the feature/setting, but it isn't enabled due to this logic? I am mainly thinking about how we avoid silently falling back to file storage.
There was a problem hiding this comment.
On top of your recommandations I added another commit that hides the checkbox field on unsupported operating systems (Linux)
EhabY
left a comment
EhabY
left a comment
There was a problem hiding this comment.
Overall the shape matches what we did in VS Code, nice!
| fun login(token: String): String { | ||
| context.logger.info("Storing CLI credentials in $coderConfigPath") | ||
| return exec( | ||
| fun login(token: String, feats: Features = features): String { |
There was a problem hiding this comment.
This adds the write side of keyring but not the read side. VS Code has a second feature flag keyringTokenRead for CLI 2.31.0+ that calls coder login token --url <url> so the plugin can pick up tokens a user wrote with coder login in their terminal. Worth adding here, or filing a follow-up?
There was a problem hiding this comment.
I would raise a new ticket for this part honestly. Sounds like a new feature, probably some code will have to be reworked. I will check with @matifali if this feature makes sense for Coder Toolbox, but good point - thank you for bringing that up.
There was a problem hiding this comment.
@EhabY I talked with Atif and raised https://linear.app/codercom/issue/DEVEX-403/add-terminal-login-token-pickup-to-coder-toolbox
There was a problem hiding this comment.
Same gap on the delete side: this adds the keyring write (login) but nothing removes the entry. VS Code pairs it with a best-effort coder logout --url <url> --yes (cliCredentialManager.ts deleteToken). Toolbox logout() only stops polling today, so once keyring is on the token lives in the OS keychain and survives data-dir cleanup and reinstall with no way for the plugin to reclaim it. Worth folding into DEVEX-403 or a sibling ticket.
| /** | ||
| * Runs a process and waits for it to finish. | ||
| * | ||
| * The wait is intentionally unbounded. Only exit code 0 is accepted by default. |
There was a problem hiding this comment.
For reference, the VS Code side has a 60s timeout
There was a problem hiding this comment.
🤔 even when you start workspaces?
There was a problem hiding this comment.
In the VS Code extension the 60s timeout is scoped to the short credential commands only (coder login, logout, login token) in cliCredentialManager.ts. Long-running commands like coder start run through a separate unbounded spawn that streams output (api/workspace.ts), so workspace start is never under the 60s cap.
Maybe make the timeout a per-call parameter (short bound for login/header/credential calls, unbounded for coder start and ssh), and close the child's stdin so an unexpected prompt hits EOF instead of hanging. VS Code does proc.stdin.end() on the long-running spawn; runProcess currently leaves stdin connected.
only when the settings are changed, instead of every login/ws startup.
3 participants
Delegate session token persistence to the Coder CLI's OS keyring backend (macOS Keychain, Windows Credential Manager) instead of always writing them in plaintext under the plugin's data directory. This brings the Toolbox plugin in line with the VS Code extension and reduces on-disk exposure of long-lived credentials.
This change is gated on two prerequisite refactors of how we currently hand the token to the CLI, both of which land in this commit:
coder logininstead of appending--token <value>to the process arguments.We’re making this change for security reasons. Command-line arguments are more likely to be exposed through process listings, shell history, CI/job logs, and command auditing, while environment variables have a smaller exposure surface on typical systems. This aligns the plugin with the Coder CLI guidance that prefers CODER_SESSION_TOKEN over
--token.By default,
coder logintreats a supplied token as a bootstrap credential: it authenticates with it once and then mints a brand-new API key via CreateAPIKey, persisting that new key as the session. The token the user (or our OAuth2 flow) handed us is discarded. For Toolbox this is wrong: we want the CLI and the plugin to share the exact same session token so that revocation, logout, and token lifetime stay consistent across both sides.And additional thing that we had to change was to replace zt-exec with a small internal ProcessBuilder-based runner so subprocess failures stay under our control.
We needed to remove ProcessExecutor because its exception messages include the spawned process environment. Now that CLI auth is passed through CODER_SESSION_TOKEN, failures could spill tokens into logs before our own
sanitization had a chance to run. That made reliable redaction impossible at the logging layer.