Prevent duplicate CLI sign-ins and show the correct wizard when switching deployments by fioan89 · Pull Request #388 · coder/coder-jetbrains-toolbox

fioan89 · 2026-11-11T19:38:46Z

Toolbox can request the setup page more than once during startup. The plugin now starts saved-session restore once, when it opens the wizard. Later page requests reuse that attempt. When Toolbox restores an OAuth session, it signs the CLI in once and saves the current token. If saving the credentials fails after sign-in, the plugin logs the error and keeps the workspace list open.

Opening a workspace link for another deployment could also leave the previous wizard on screen until Toolbox regained focus. After the user accepts the switch, the plugin now cancels the previous connection attempt and explicitly shows the target deployment’s wizard so the workspace link can proceed immediately.

Manual regression checks

Start Toolbox with saved credentials and open the Coder provider while sign-in is in progress. Verify that the CLI signs in once and the workspace list stays visible.
While Toolbox is reconnecting to deployment A, open a workspace link for deployment B and accept the switch. Verify that B’s workspace opens without switching away from Toolbox and back.
Opened a link to deployment B with Toolbox already running and again after quitting it while signed in to A. After consent, B reached workspace lookup without a focus change. A second link for the same account proceeded without another prompt.
Switched to a previously remembered B. Both Toolbox and the CLI picked up B’s token without a trust prompt. After a restart, Toolbox restored the accepted session and recreated the CLI credentials.
Cancelled a switch from A to an unknown B and verified that A stayed connected. On a cold launch, accepting B with an invalid token showed B’s sign-in error and left B untrusted.
Completed sign-in while Settings was open. Settings stayed visible, and returning to setup opened the workspace list once.

Toolbox can show the connection step more than once during startup. A second CLI login could fail after the first succeeded and send the user back to token entry. The wizard now starts one connection attempt at a time. A retry waits for the cancelled attempt to finish, and only the active attempt can publish a session or report a failure. Saved sessions restore behind the workspace list. If restoration fails, the wizard opens the sign-in form so the user can reconnect.

A workspace link for another deployment could leave the previous setup page visible until Toolbox regained focus. The provider now displays the replacement wizard as soon as it handles the link, so setup can continue while Toolbox stays in focus.

jeremyruppel

Two medium findings inline. I ran ./gradlew test on this head and all tests passed.

Generated by Coder Agents on behalf of @jeremyruppel.

An OAuth credential update can fail after the provider accepts the session. Treating that error as a failed sign-in sends the user back to setup even though the workspace connection is active. The wizard now logs the error and keeps the signed-in session open. A regression test covers a credential store that rejects the update.

Setup logs the CLI in with the current OAuth token. Calling the token refresh handler again after sign-in repeats that login and can leave the CLI and the saved session out of sync. The wizard now saves the OAuth session directly after setup. The refresh handler still updates credentials when a running session receives a new token. A test checks the login count and saved token.

The provider tests use short deployment names and repeat the setup for several credential choices. This makes it hard to see which deployment receives a link and which credentials the wizard should use. The tests name the source and target deployments and cover the restore choices in a table. Their assertions identify when the CLI signs in and which workspace page the provider opens.

Setup assumes a token exists when it hands credentials to the CLI. If the user switches from certificate to token authentication during setup, a missing token can produce an error with no explanation. The HTTP client and CLI now use the same token check. The wizard reports a missing token and skips CLI login for certificate sessions. Tests cover both paths.

Looking up a page to display can start a CLI sign-in. The wizard also uses a separate step and a flag to track how the connection started. The router now starts a saved-session restore when it registers the wizard. Looking up the page only selects what Toolbox displays. The wizard records the origin of the connection so a failed restore can show the sign-in form and repeated callbacks reuse the active job.

Main contains the setup wizard fixes from PR #388 as a squash commit. The redirects branch already includes those fixes through its original parent. The merge keeps the shared session token check and scopes the authentication header to the configured deployment.

fioan89 added 2 commits November 11, 2026 21:18

fioan89 requested review from code-asher, jeremyruppel, matifali and untra November 12, 2026 05:27