feat: add OS keyring support for session tokens#307
Draft
fioan89 wants to merge 8 commits into
Draft
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
zedkipp
reviewed
May 20, 2026
| } | ||
|
|
||
| private fun shouldUseKeyringAuth(feats: Features): Boolean = | ||
| context.settingsStore.useKeyring && feats.keyringAuth && supportsKeyringStorage(currentOs) |
Contributor
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.