[Bug] agent-device opens another T3 instance and marks running Cursor sessions as lost

Start with the generated agent-device launcher and the resolveNodeExecutable path to verify how the CLI is started. Then inspect reconcileProviderSessions and the isolated recovery test described in the issue. Done means device commands return CLI output without opening T3, and a second backend cannot change another backend's running session state.

I had three Cursor CLI threads running in T3. Extra T3 instances started opening, and the threads showed:

Provider session did not survive a server restart. Send a new message to continue.

But the agents were still working. The logs show fresh tool calls after that error in all three threads, with two continuing for more than ten minutes. This made it hard to know whether anything had actually stopped or whether sending “continue” would make things worse.

What triggered it

The first extra instance came from an agent running T3’s generated agent-device help command during iOS UI verification. The command’s output contains a desktop startup log, with the same run ID as the extra instance in T3’s desktop trace.

Later, agent-device version and agent-device install also launched extra instances. Two threads are confirmed to have triggered this; the third was affected without calling agent-device itself.

What the investigation found

The generated launcher on my machine contains this:

#!/bin/sh
exec '/Applications/T3 Code (Nightly).app/Contents/MacOS/T3 Code (Nightly)' '<T3_STATE>/device/bin/agent-device-launcher.mjs' "$@"

It invokes the Electron app without explicitly setting ELECTRON_RUN_AS_NODE=1. In this build, resolveNodeExecutable returns the Electron executable, and the helper ends up opening T3 instead of running the device CLI.

The extra app starts a backend on another port using the same T3 state. During startup, reconcileProviderSessions sees no providers in that new process and treats the original server’s sessions as lost. The original Cursor workers keep running.

An isolated test against the shipped source confirms that this recovery path marks the sessions as stopped/error without calling stopSession or interruptTurn. The continued execution is separately confirmed by the real thread logs. This wasn’t a full reproduction with two live servers.

I’d expect the device helper to return CLI output without opening another app, and a second backend to be prevented from changing another running backend’s session state.

Environment

• T3 Code: 0.0.43-nightly.20260921.2044, commit 5781b5240bd5
• macOS 27.0 (26A428)
• Installed Cursor CLI: 2026.09.18-9a7762b
• Incident: September 21, 2026

PR #12241 describes the same failure and was closed without merging. It looks relevant here because the generated launcher in this build still has the problem.

I have a sanitized timeline, command/startup excerpts, and the isolated test ready to share. The investigation hasn’t established why the desktop single-instance guard allowed these launches.