fix(desktop): slash commands target the user's chat, not a new session

[teknium1]

Infographic

Summary

Desktop slash commands now run against the chat the user is looking at, instead of silently creating a new session to run against.

Reported symptom: start a goal in the desktop app, then type /goal status — it answers "No active goal" for a goal that is live.

Root cause: /goal state is persisted per-session in SessionDB (state_meta key goal:<session_id>), so the slash and submit pipelines must agree on which session id they mean. They didn't. slash.ts's ensureSessionId resolved with a bare hint || activeRef || createBackendSessionForSend(), so whenever the runtime binding was momentarily absent — profile swap, reconnect, orphan-reap, request timeout — it minted a new session and ran the command there. submit.ts already handles that case correctly by resuming the routed stored session on its owning profile (#55578, #67603).

This is a whole-class fix, not a /goal patch: every exec/rpc slash command (/usage, /status, /tools, /agents, …) shared the hole.

Changes

• resolve-target-session.ts (new): one shared resolution ladder, per the "one resolver owns each policy" rule in apps/desktop/AGENTS.md.
  1. explicit runtime id from the caller (queue drain / tile)
  2. the live runtime ref — unless a durable route disagrees with it (a stale ref from the previous profile must not capture the command)
  3. session.resume on the routed (else selected) stored session, re-registered on the profile that owns it
  4. only a genuine new-chat draft creates a session
• slash.ts: ensureSessionId delegates to the shared resolver; threads getRoutedStoredSessionId + getRuntimeIdForStoredSession.
• index.ts: passes the two new deps through.
• A targeted durable conversation whose runtime cannot be rebound returns null rather than forking — reporting that a command could not run beats running it against the wrong session.

Validation

	Before	After
/goal status with runtime binding absent	slash.exec on brand-new-session → "No active goal"	session.resume → slash.exec on the routed session
routed session un-rebindable	forked a contextless chat	no fork, command reports failure
desktop suite	—	2968 passed, 3 skipped, 0 failed
tsc --noEmit	—	clean
eslint	—	clean (1 pre-existing harness warning, untouched)

10 new regression tests (8 resolver-level, 2 at the /goal level reproducing the reported symptom).

Sabotage-verified — the tests were re-run with the resolver body reverted to the old hint || activeRef || createSession() ladder to prove they actually catch the bug rather than passing vacuously: 6 of 10 fail, including both /goal-level tests. Restored and re-verified green afterward.

Notes

• PR fix(desktop): reuse slash-created runtime session after /goal #63376's one-line payload (prefer activeSessionIdRef.current over the stale prop) is already on main at submit.ts:180 — that fixed the submit side of [Bug]: Desktop submit fails after /goal; local session row created but message never reaches backend #63352. This fixes the slash side, which was the remaining half.
• Likely also closes [Bug]: Desktop submit fails after /goal; local session row created but message never reaches backend #63352 ("Desktop submit fails after /goal; local session row created but message never reaches backend") — same forked-session seam, seen from the submit direction. Worth confirming before closing it.
• Found while investigating: the /goal command.dispatch handler in tui_gateway/server.py does not bind session["profile_home"], while the turn thread does. Latent divergence for app-global remote mode; goals land in the launch state.db either way today, so it is not this symptom and is left alone here.

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 344ef09}

all good!