Repository navigation
fix(ssh): reconnecting no longer locks out the remote's background service - #23
Draft
not-compromised wants to merge 1 commit into
Draft
not-compromised wants to merge 1 commit into
not-compromised wants to merge 1 commit into
Conversation
…ground service A background service has no server for a few seconds while it restarts or updates. An SSH launch that landed in that gap started its own server, which took the home's ownership lock; the service's next server then exited with "another server owns this home" and its launcher idled until someone stopped the SSH-started server by hand. The launch now checks for a loaded background service for the remote home (systemd or launchd, plus the home's service-state.json) and waits up to 30 seconds for its server before starting one of its own.
not-compromised
marked this pull request as draft
November 5, 2026 14:09
Owner
Author
|
Marked draft by the orphan sweep (owner, 2026-10-28: "just turn all orphans to drafts for now"): open and ready, but ci-failure for 30.5h, no update for 30.5h on GitHub. Mark it ready again to resume. |
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.
Problem
If a desktop app reconnects over SSH while the remote machine's background service is restarting or updating, the app starts its own server there. That server takes the T3 home, the service's new server exits with "another server owns this home", and the service then sits idle until someone stops the app's server by hand. If the desktop app is older than the service, the machine silently runs that older server; settings it doesn't know are dropped with "This environment does not support this setting."
Change
If the remote home has a running background service (systemd or launchd), an SSH launch now waits up to 30 seconds for that service's server and connects to it instead of starting its own.
Scope and approval
A small fix for a bug seen on two machines during a nightly update. No upstream issue exists yet.
Verification
A new test runs the real launch script under
shagainst a stand-in service that is mid-restart. Without the fix, the launch starts its own server; with it, it connects to the service. A second test confirms hosts without a service don't wait. Typecheck, lint and format pass forpackages/ssh. Vitest could not run in my sandbox, so both tests ran through the same file under plain Node. They have not run in CI yet.Not covered: an SSH-started server that is already running is still reused on reconnect, and the idle service does not recover on its own.
Claude Opus 5.5 via T3 Code