fix(cursor): pre-register cursorSessionId on resume before ACP session/load completes

[swear01]

Summary

When resuming an inactive Cursor session, the hub spawns a new CLI process and calls ACP session/load. For several seconds the new hapi session has no cursorSessionId in metadata, breaking dedup, picker gating, and resume-unavailable checks on the web.

Repro

1. Spawn Cursor session, wait for cursorSessionId.
2. Send message, archive.
3. POST /api/sessions/:id/resume.
4. Poll GET /api/sessions/:newId — metadata.cursorSessionId is null for ~0–6s, then populated with the same ACP thread id.

CLI log shows: cursor --resume <cursorSessionId> --hapi-starting-mode remote --started-by runner.

Root cause

cursorAcpRemoteLauncher calls backend.loadSession() then onSessionFoundWithProtocol(). Metadata is written only after load completes. Zed fixed an analogous race in PR #54431 by registering the session before awaiting session/load.

Proposed fix

1. On resume bootstrap, immediately write pending cursorSessionId (+ cursorSessionProtocol: 'acp') from hub resume token into metadata (via bootstrapExistingSession + pickExistingSessionMetadata, or hub-side merge on spawn).
2. Optionally coalesce in-flight resume for same cursorSessionId (Zed pending_sessions pattern, PR #53999).

Related

• Cursor sessionId can be cleared from session metadata on crash-archive, blocking future resume even when chat data is on disk #820 (resume token cleared on crash-archive — different path, same symptom family)
• Zed PR #54431, PR #53999

Test plan

• CLI test: resume path sets metadata before load resolves (mock backend).
• Live: resume → assert cursorSessionId present within first GET /api/sessions/:id.

[github-actions]

Confirmed from current code: the Cursor ACP resume path does not pre-register the resume token in metadata before session/load completes. The resumed CLI receives the token from the hub, but cursorSessionId is only written after ACP returns an id and onSessionFoundWithProtocol() runs. That matches the race described here: until that metadata update arrives, hub/web code that depends on metadata.cursorSessionId cannot see the resumed Cursor thread id.

I also did not find an existing in-flight coalescing path for Cursor resume by cursorSessionId. There is dedup by agent session id after metadata exists, but that cannot run during the initial metadata gap.

Relevant code:

• hub/src/sync/syncEngine.ts:656 - resume resolves the local target and reads the stored agent id.
• hub/src/sync/syncEngine.ts:703 - hub spawns the replacement CLI and passes resumeToken as resumeSessionId.
• cli/src/cursor/cursorAcpRemoteLauncher.ts:97 - Cursor ACP resume waits for backend.loadSession().
• cli/src/cursor/cursorAcpRemoteLauncher.ts:121 - onSessionFoundWithProtocol(acpSessionId, 'acp') runs only after load/new session completes.
• cli/src/cursor/session.ts:49 - onSessionFound metadata application writes cursorSessionId.
• cli/src/agent/sessionFactory.ts:204 - existing-session bootstrap preserves current metadata and applies overrides, but no pending Cursor resume override is passed in the inspected path.
• hub/src/sync/sessionCache.ts:786 - dedup only extracts cursorSessionId once present in metadata.
• web/src/lib/sessionResume.ts:14 - web resume gating resolves Cursor resumability from metadata.cursorSessionId.

No more info needed from the report as written.

---

HAPI Bot