[Remote MCP] Device is online and ping/list_devices work, but first start_process fails; persisted session forces re-auth

Summary

Remote Desktop Commander 0.2.47 can be freshly paired and reaches Channel subscribed / Device ready. Remote meta calls such as ping and list_devices work, but the first real shell execution through start_process fails at the ChatGPT/Remote MCP tool layer even for a trivial command.

There is a second reproducible symptom: after stopping and restarting desktop-commander remote, the client logs Found persisted session for device ... but immediately starts a new device authorization flow instead of reusing that session.

This appears related to #622, but differs in an important way: a freshly issued session here does reach Device ready, stays online, and answers meta calls before start_process fails.

Environment

• Host OS: Linux / Proxmox VE 9.2.x (Debian-based)
• Desktop Commander: 0.2.47
• Node.js: 24.19.0
• Execution: npx --yes @wonderwhy-er/[email protected] remote
• Remote MCP: https://mcp.desktopcommander.app
• Client: ChatGPT Remote MCP connector
• Agent kept alive in a single tmux session; systemd auto-restart disabled for the final reproduction

No access tokens, refresh tokens, email addresses, or device IDs are included below.

Clean setup performed before reproduction

1. Removed the ChatGPT Remote Desktop Commander connector.
2. Revoked all old devices in the Remote Desktop Commander dashboard.
3. Stopped and disabled the previous systemd service.
4. Moved the old local device file out of the way.
5. Ran a fresh desktop-commander remote authorization.
6. Browser authorization succeeded.
7. Client reported:

Authorization successful!
Device ID assigned: ...
Channel subscribed
Device marked as online
Presence tracked
Device ready

1. Kept that exact process running continuously inside tmux.
2. Reconnected the ChatGPT Remote MCP connector.

Reproduction A: meta calls work, start_process fails

With the freshly paired device online:

1. Call ping for the device.
   • Result: success (pong).
2. Call list_devices.
   • Result: success; device reports online, version 0.2.47, auth token valid.
3. Immediately call start_process with a trivial command and a 3-second timeout:

printf 'echo-test-ok\n'

Actual behavior

The start_process invocation fails/disappears at the ChatGPT/Remote MCP tool layer instead of returning the command output. This reproduces even though ping and list_devices worked immediately beforehand and the remote agent remains online.

Expected behavior

start_process should return echo-test-ok and leave the remote device usable.

Reproduction B: persisted session is found but not reused

1. Fresh pairing succeeds and reaches Device ready.
2. Stop the process gracefully with Ctrl+C.
3. Start the same command again:

npx @wonderwhy-er/desktop-commander@latest remote

1. The client logs:

Found persisted session for device ...
Authenticating with Remote MCP server...
Starting device authorization flow...
Requesting device code...

So a persisted session is detected, but a completely new authorization flow is started anyway.

If that second authorization flow is aborted with Ctrl+C, shutdown includes:

No valid session for offline update

Additional observations

• The problem is not caused by a long-running command, shell pipe, or complex process. The failing command is only printf.
• The remote agent itself is reachable and online immediately before the failing process call.
• Using a long-lived tmux process avoids automatic restarts and repeated background pairing attempts, but does not fix the start_process failure.
• A previous systemd unit used Restart=always; disabling it removed restart churn but did not remove the underlying bug.
• Multiple old device/session entries had accumulated during repeated pairing attempts, so all devices were revoked and the reproduction was repeated from a clean pairing state.

Why this seems distinct from #622

In #622 the newly issued session fails before the device reaches Channel subscribed / Device ready. Here the fresh session successfully reaches Device ready, stays online, and responds to ping and list_devices; failure appears when invoking the process-execution tool and separately when attempting to reuse the persisted session.

I can provide additional non-secret logs or run narrowly scoped read-only diagnostics if useful.