[lukeroberts]

Summary

• preserve the active registry connection as the owner fallback when a remote session row has no connection_id
• keep stored-session reads, session.resume, and follow-up prompt.submit on that same (connection, profile) route
• add regression coverage for both opening an untagged remote row and sending the next prompt

Problem

The unified Sessions list normally tags registry-owned rows with connection_id, but a direct connection switch can reload rows without that tag. In a multi-gateway setup, an untagged remote row whose profile is default can then be resolved as only default.

That profile name is not globally unique: both the local gateway and an SSH/remote gateway can own a default profile. The renderer consequently falls back to the ambient/local dispatcher. The remote session still exists, but session.resume reaches the local backend and fails with resume failed, session not found. Even after a successful resume, the prompt pipeline had its own ambient dispatcher and could fail the next message with session not found for the same reason.

This can affect other users with multiple registered gateways and legacy/untagged session rows, particularly local + SSH/remote configurations where both sides use the default profile name.

The behavior became reachable when the unified cross-gateway Sessions list was introduced in d354af5 (feat(desktop): unified Sessions list shows every connected gateway's chats (#88880), Aug 18, 2026). Later profile-routing fixes covered explicit owner metadata, but not this connection-less fallback or the separate prompt submission path.

Fix

For an untagged row, use the active registry connection as an ambient owner only when the current connection is remote. Explicit owner hints and persisted connection_id values continue to take precedence, and local mode is unchanged.

The resolved connection is then used consistently for:

• stored-session REST scope
• session.resume / session.activate / session.usage
• follow-up prompt.submit

Test plan

• npx vitest run src/app/session/hooks/use-prompt-actions/index.test.tsx src/app/session/hooks/use-session-actions.test.tsx (183 passed)
• npm run typecheck
• ESLint on all four modified Desktop files (no errors; one pre-existing exhaustive-deps warning in the prompt test harness)
• git diff --check
• npm run pack
• Live local + SSH gateway verification: reopened the original affected remote session, submitted a follow-up prompt, and confirmed both the prompt and response were persisted in the remote gateway's state database

[rollingonchrome]

I reproduced the same local+SSH default-profile failure against this branch on a Wintermute thin client: the previously failing remote stored session resumed successfully after #93451, but submitRewindPrompt still used the ambient dispatcher for regenerate/edit/restore.

I opened a dependent PR that completes the rewind/resubmit path, keeps one captured owner through history lookup, interrupt, session-not-found recovery, busy retry, and stale-target resume, and aborts edit recovery if foreground selection changes while resume is pending:

lukeroberts#1

Verification on the dependent diff:

• three red→green owner-routing regression tests
• 219 focused tests passed
• full Desktop UI suite: 5,618 passed across 585 files
• typecheck passed
• ESLint: 0 errors; one pre-existing Harness warning
• macOS arm64 package build passed

The existing affected remote session remained read-only; resume succeeded without Session not found. A disposable live prompt attempt was interrupted by a separate full Desktop process exit before any prompt.submit frame was emitted, which is disclosed in the dependent PR rather than presented as successful end-to-end prompt/regenerate validation.

[jakewvincent]

Confirmed as an independent, high-impact real-world case of this SSH/remote routing failure.

Environment: macOS Hermes Desktop connected primarily through a registered SSH gateway to a Linux host. Both the Mac client and gateway host were updated together and are on the same current Hermes generation (the gateway checkout is current 057dcdf).

Observed behavior:

• Opening conversations from both Pinned and the ordinary session list usually renders the persisted transcript, then surfaces Session not found; the conversation cannot be continued.
• The durable rows and transcripts are still present in the remote/default state.db (archived=0, hidden=0), so this is not deletion or corruption.
• A small subset of otherwise similar sessions still works, with no durable-row property that explains the split; that is consistent with missing/mis-scoped ephemeral connection/runtime bindings rather than bad session data.

This makes the Desktop effectively unusable for an SSH-gateway-first workflow: the normal way to return to most prior conversations is broken even though their histories are intact. The local + SSH/remote default-profile ambiguity described in this PR is a strong match.

Happy to provide redacted gateway logs or help validate this branch against the affected setup.

[teknium1]

Merged via #95080 at 682a34a — your commit was cherry-picked into the consolidated salvage PR with authorship preserved, so this work carries your name in git history.

Thanks for preserving remote session routing — your fix kept sessions pinned to the connection that owns them instead of drifting to the ambient source.

Closing this original PR now that the consolidated branch has landed on main. Thanks for contributing to the desktop multi-gateway campaign (tracker: #94724).