Repository navigation
remote.spin.cliPath read in every window: application scope - #17
Merged
Merged
Conversation
A window that lost its connection is reconnected by VS Code resolving spin+<workspace> again, and by then it is a remote window, which reads a machine-scoped setting from the remote and not from the person's settings: remote.spin.cliPath came back empty, and the reconnect ran the spin on the PATH instead of the one named. Every setting here is of the machine the resolver runs on, the window's, so each is application-scoped, which every window reads from the person's settings; the manifest test holds them to it. Found by vscode-spinbox's spin+ lane in a real VS Code against spin's e2e stack: the tunnel cut under a connected window, VS Code resolved again with an older spin and gave up; with this, the window is back in 1 s with the same terminal shell. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
aledbf
added a commit
to spin-stack/vscode-spinbox
that referenced
this pull request
Nov 14, 2026
spinbox.cliPath is a path on the machine the extension runs on, the window's (extensionKind ui), never the workspace's. A machine-scoped setting is not read from the person's settings once a window is remote: Spinbox Remote's remote.spin.cliPath, scoped the same, came back empty while VS Code reconnected a window, and the reconnect ran another spin (spin-stack/open-remote-ssh#17). Application scope is read from the person's settings in every window; the manifest test holds it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
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.
When a window loses its connection, VS Code reconnects it by resolving
spin+<workspace>again. By then it is a remote window, and a remote window reads amachine-scoped setting from the remote, not from the person's settings. Soremote.spin.cliPathcame back empty, and the reconnect ran whateverspinwas on the PATH.Every setting here belongs to the machine the resolver runs on, which is the window's machine. So each one is now
application-scoped, which every window reads from the person's settings, andtest/package-manifest.test.tsholds them to that. The test fails without the change.How it was found
vscode-spinbox's new
spin+lane runs in a real VS Code 1.146.0 against spin's e2e stack. It cuts the tunnel under a connected window. VS Code resolved again, ran/usr/local/bin/spin(v20260928, which has no--no-open), and gave up for good. With this change, the window is back in about 1 s and has the same terminal shell (same pid).Part of spin-stack/vscode-spinbox#24.
🤖 Generated with Claude Code