[ScriptedAlchemy]

An SSH login that cannot reach the systemd user manager can still have an installed T3 Code service. The launcher treated a failed systemctl --user cat as no installed service and attempted to start a standalone server with different network settings.

Check the installed user unit before querying systemd. Check the standard unit under ~/.config and any absolute XDG_CONFIG_HOME. The SSH login can use a different config home from the session that installed the service. Keep the systemd query for units found through other manager paths. Existing launchd handling and standalone bootstrap remain covered by the same shell test table.

Validation:

• Added the installed-unit/unreachable-manager case to the existing real-shell test first. It failed on main with Failed to find an available port after reaching standalone port selection, instead of refusing replacement with t3 service restart.
• All 29 SSH tests pass, including different installer and SSH login config homes, default and custom XDG paths with spaces, relative XDG fallback, existing manager detection, and no-service bootstrap.
• npm_config_offline=true vp run check:changed origin/main passed.

Shell regression evidence:

Before: installed unit + systemctl exit 1 -> standalone-attempt marker created
After:  installed unit + systemctl exit 1 -> t3 service restart; no standalone-attempt marker

These tests execute the generated POSIX shell with temporary files and stubbed OS/service commands. They do not claim a live Linux SSH or systemd integration run.

Model: Codex (exact model identifier not exposed). Harness: Codex desktop.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 4a0c262

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR