Cursor's undocumented 'desktop' command turns local AI agents into a scriptable control channel

RuntimeWire reports that it extracted the packaged JavaScript from Cursor's stable Windows x64 build 3.16.17 and found a working, gated feature called Desktop Bridge that lets the bundled cursor CLI enumerate agent threads open in Cursor Desktop and submit follow-up instructions to them ^[1][2]. That matters because it makes the local agent surface an authenticated, scriptable control channel, and according to RuntimeWire, Cursor's CLI guide and CLI changelog contained no reference to cursor desktop or Desktop Bridge when reviewed on August 18, 2026 ^[3].

The command surface is small: cursor desktop ls and cursor desktop send <thread> [text...] ^[4]. In a reporter-owned test, cursor desktop ls --json returned the prepared thread's ID, title, completed status, local source and window ID ^[5]. cursor desktop send then reported the follow-up as submitted, and Cursor Desktop displayed the terminal-sent instruction and returned the exact requested response, DESKTOP-BRIDGE-LIVE-OK, inside the original conversation ^[6][7].

This is not orphaned code. RuntimeWire says the packaged application contains the cursor desktop CLI parser and help text, an authenticated local Desktop Bridge service, a gated Beta settings card, and desktop handlers for listing and messaging agent threads ^[8]. Its teardown traced the desktop_bridge feature gate, a disabled-by-default user setting, local bridge startup, a discovery mechanism, bearer authentication, the CLI commands and the desktop message handlers ^[9]. A discovery mechanism plus bearer auth plus a message handler is a service, not a stub.

Reaching it took deliberate local work. RuntimeWire launched Cursor with its built-in smoke-test driver, real agent HTTP and a test-feature override, enabled "Allow CLI to access desktop agents" in Settings then Beta, and restarted with the same arguments ^[10][11]. The override was supplied as the base64 --test-feature-flags value eyJkZXNrdG9wX2JyaWRnZSI6dHJ1ZX0= ^[12], which decodes to {"desktop_bridge":true} ^[13]. So the current default is off, and today's risk is not a drive-by. The consequence is that the shipped binary already carries the whole path, and the toggle is the only thing standing on it.

On provenance: the tested build is commit 6b2afae0257df2bb5e1835f15165dc2f0de056b0, built 2026-08-14 ^[14], four days before the documentation check ^[15]. RuntimeWire says it preserved screenshots and calculated SHA-256 hashes for the source archive, the relevant application files and the successful test image ^[16], and it publishes digests including 2100a37e6ddd23fd3f0adf982dcd6779a525c25f0d6acb9fa0683a44cb947592 for workbench.desktop.main.js ^[17]. The published table lists resources/app/out/cli.js without a digest beside it, a gap in an otherwise itemised record ^[18]. RuntimeWire states it independently reproduced the core finding ^[19] and that no third-party account, conversation or data was accessed ^[20]. It requested comment; the company had not responded by publication time ^[21].

Three things to watch. First, whether the desktop_bridge gate ships enabled in a later stable build, because the difference between this finding and an exposed control channel is one flag default. Second, whether Cursor's CLI guide and changelog acquire an entry, which is the cheapest signal that the feature is being managed rather than parked ^[3]. Third, the shape of the control: the reporting record describes a Beta card labelled "Allow CLI to access desktop agents" and a disabled-by-default user setting ^[8][9], which is a per-user choice. Platform owners should be asking their vendor contact whether an administrator-level policy exists to hold that setting off, and whether ls output that includes window IDs ^[5] is logged anywhere they can read.