We hit the same “Error resuming chat” toast and ran a small controlled experiment that narrows down the mechanism. Sharing data in case it helps the team, since it suggests this is more than a transient wake hiccup.
Environment: Cursor 3.14.27 (arm64), macOS 26.5.1, Apple M4 Pro Mac mini (mains-powered, no sleep), privacy disabled.
Protocol: fresh Agent chats each start one background Shell (block_until_ms: 0) running “sleep 1080 && echo SENTINEL” (or sleep 300 in later trials), the agent ends its turn immediately, and the chat is left completely idle. Two variants: with notify_on_output armed on the sentinel, and without it (standard completion notification only). Outcomes were read from the terminal state files on disk plus the UI.
Results — 0 of 4 trials resumed:
- Trial 1 (with notify_on_output): background shell was killed (status “aborted”, exit_code “unknown”) 77 seconds after the turn ended. Toast appeared. Request ID: 1d60bbdb-4e5e-4e49-ba5f-8e315b558429
- Trial 2 (without notify_on_output): shell killed the same way at 94 seconds. Toast appeared. Request ID: fe751c73-b624-4f49-8c4d-3fe49b3c2c3d
- Trial 3 (with notify_on_output): shell killed at 102 seconds. SILENT failure — no toast, no resume within 15 minutes.
- Trial 4 (without notify_on_output): shell SURVIVED, ran the full 300 seconds, exit 0, sentinel printed. Still SILENT — the UI shows “Finished …”, but the agent never resumed and no toast appeared within 14 minutes.
Both toasts carried the same client-side stack (via Copy ID):
```
ConnectError: [deadline_exceeded] Agent Execution Timed Out
at gvp (workbench.glass.main.js:9176:38322)
at Voi.waitForProviderRegistration (workbench.glass.main.js:9176:43755)
at async Jgl.\_waitForPushRequestContextProviderRegistration (workbench.glass.main.js:18950:4327)
at async aNe (workbench.glass.main.js:8489:11978)
at async Object.prepare (workbench.glass.main.js:18950:21313)
at async Jgl.\_runWakeupAction (workbench.glass.main.js:18950:18418)
at async Jgl.\_maybeDispatchBackgroundCompletions (workbench.glass.main.js:18950:23826)
at async Jgl.runIdleHooks (workbench.glass.main.js:18950:30311)
```
Three observations that may help debugging:
1. The background job itself usually dies, not just the wake. In 3 of 4 trials the tracked shell was reaped about 80-100 seconds after the owning turn ended (terminal file shows status “aborted”, exit_code “unknown”), long before the command would have finished. In the original report the watched work survived because it ran remotely on CI — locally the watcher process appears to be killed. So “work is saved” holds only for remote work.
2. notify_on_output is not the discriminator. Both variants fail identically.
3. Even a fully successful completion doesn’t resume the chat. Trial 4’s shell ran to completion (exit 0) and the UI shows “Finished …”, but the agent turn never continued and no toast appeared — a silent stall, which is worse than the toast because there is no signal at all.
For anyone needing a workaround until this is fixed: don’t let an agent turn end while a tracked background shell is running. For jobs that must outlive the turn, detach into a new session and read a log file on the next message. Note that plain “nohup … & disown” is also killed at tool-call boundaries in this environment, and setsid doesn’t exist on macOS, so we use:
```
python3 -c “import subprocess,sys; p=subprocess.Popen([‘bash’,‘-c’,sys.argv[1]], stdout=open(sys.argv[2],‘w’), stderr=subprocess.STDOUT, stdin=subprocess.DEVNULL, start_new_session=True); print(p.pid)” ‘’ /tmp/job.log
```
This pattern (plus polling in slices of 3 minutes or less when staying in the turn) went 2 for 2 in the same test session, including one 27-minute turn.
Happy to run more trials or provide the terminal state files if useful.
