[BUG] Desktop Projects: thread loses auto-approve after the device bridge reconnects; every command then needs manual approval and there is no mode control to restore it

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

I use a Claude Projects thread from the Windows desktop app to work on a dev server that I reach over SSH. When the thread starts it auto-approves commands, as configured.

If the PC is left idle for a while, the desktop app's device bridge socket to wss://bridge.claudeusercontent.com closes abnormally (1006) and reconnects a few seconds later. After that, the same thread asks for manual approval on every command, and auto-approve never comes back.

Project threads have no permission-mode picker, so the thread can't be switched back. The only workaround is to start a new thread every time, which loses the conversation context.

As far as I can tell from the local logs, the thread runs in the cloud and drives the machine through the device bridge (device_bash, device_list_dir, ...). No approval or permission state is logged locally, so the auto-approve state seems to be dropped on the server/bridge side when the device reconnects, not by anything on my machine.

What Should Happen?

A device-bridge reconnect should not change the thread's approval behaviour. The thread should keep auto-approving after the bridge comes back. Failing that, project threads should have a control for turning auto-approve back on without starting a new thread.

Error Messages/Logs

# %LOCALAPPDATA%\Claude\logs\main.log (desktop app 2.19675.0)
# The bridge drops and reconnects many times a day while the PC is idle:
2026-10-05 11:27:03 [info] [remote-tools-device] socket closed: 1006
2026-10-05 11:27:03 [info] [remote-tools-device] reconnect #1 in 1784ms
2026-10-05 11:27:05 [info] [remote-tools-device] authenticated
2026-10-05 12:07:26 [info] [remote-tools-device] socket closed: 1006
2026-10-05 12:07:26 [info] [remote-tools-device] reconnect #1 in 3874ms
2026-10-05 12:07:31 [info] [remote-tools-device] authenticated
2026-10-05 14:08:41 [info] [remote-tools-device] socket closed: 1006
2026-10-05 14:08:41 [info] [remote-tools-device] reconnect #1 in 2416ms
2026-10-05 14:08:43 [info] [remote-tools-device] authenticated
2026-10-05 15:42:47 [info] [remote-tools-device] socket closed: 1006
2026-10-05 15:42:47 [info] [remote-tools-device] reconnect #1 in 2918ms
2026-10-05 15:42:50 [info] [remote-tools-device] authenticated
2026-10-05 16:52:49 [info] [remote-tools-device] socket closed: 1006
2026-10-05 16:52:49 [info] [remote-tools-device] reconnect #1 in 3410ms
2026-10-05 16:52:53 [info] [remote-tools-device] authenticated
2026-10-05 19:50:07 [info] [remote-tools-device] socket closed: 1006
2026-10-05 19:50:07 [info] [remote-tools-device] reconnect #1 in 2514ms
2026-10-05 19:50:10 [info] [remote-tools-device] authenticated

# Tools registered on the bridge (abridged):
[remote-tools-device] connecting DO bridge with: get_device_info, device_list_dir, device_stage_files,
  device_commit_files, ..., device_request_folder_access, device_request_delete_permission, device_bash, ...,
  project_memory_read, project_memory_write

# Separately, the SSH host's own settings can't be used as a workaround, because the app ignores them:
[warn] [SettingsResolver] Ignoring defaultMode "auto" from remote /root/.claude/settings.json — remote-read settings cannot default to an escalating mode

Steps to Reproduce

1. In the Claude desktop app on Windows, open a Project that works against a dev server over SSH.
2. Start a thread with auto-approve on and have it run a few shell commands. They run without prompts.
3. Leave the PC idle (screen off / sleep) until main.log shows [remote-tools-device] socket closed: 1006 followed by reconnect #1 ... authenticated. This happens within minutes to an hour.
4. Send another message in the same thread that makes Claude run a command.
5. Every command now shows an approval prompt. There is no permission-mode control in the thread to turn auto-approve back on.
6. Only a new thread auto-approves again, until the next bridge reconnect.

Things I tried that didn't help:

• permissions.defaultMode: "auto" in the server's /root/.claude/settings.json (ignored; see the SettingsResolver line above)
• permissions.defaultMode: "auto" in the local ~/.claude/settings.json on Windows

Claude Model

Not sure / Multiple models (happens on every model I've used)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude desktop app 2.19675.0 (Windows); remote CLI on the SSH host: 2.1.286

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other (Claude desktop app, Projects)

Additional Information

Windows 11 Home (10.0.26200). The dev server is Ubuntu, connected over SSH as root.

Possibly related, but not the same bug:

• #99688: project cloud threads are server-side bound to the desktop device
• #98480: device bridge flaps when the machine is unattended
• #94613: auto-update kills the remote-tools-device connection
• #67933: an SSH reconnect respawns sessions and silently drops their Remote Control flag (same pattern of a setting lost on reconnect)