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
May 20, 2026 21:30
zedkipp
reviewed
May 20, 2026
fioan89
marked this pull request as ready for review
May 22, 2026 05:26
EhabY
reviewed
May 22, 2026
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!
only when the settings are changed, instead of every login/ws startup.
EhabY
approved these changes
Jun 18, 2026
Collaborator
Author
|
reminder for me: check this comment #361 (comment) later when we bring the PR up to date. |
…nto-os-keyring Default to OS keyring storage when useKeyring is unset; false opts out. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…unner The process runner could return control to its caller while a timed-out or cancelled child process was still exiting. Forcibly destroying a process only sends the kill signal, and the JVM reaps the child asynchronously, so the operating system kept reporting the process as alive for a short window. This made the timeout test flaky on slower CI runners, where it observed the child before the JVM had finished reaping it. We changed the runner's cleanup to wait briefly for the child to exit after sending the kill signal, so callers no longer observe a child that is still exiting. We bounded the wait to one second because a killed process normally exits within milliseconds, even on a heavily loaded machine, while a process stuck in uninterruptible I/O could otherwise block cancellation indefinitely.
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
3 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.