[BUG] Cowork: desktop device bridge authenticates but device tools are never provisioned into newly created sessions (works in pre-existing sessions)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Since the Chat + Cowork "Home" merge (~July 7, 2026), the desktop device bridge no longer works in newly created Cowork/Home sessions. The bridge connects and authenticates and the connected device is advertised in the session context, but the actual device tools return "No such tool available". Sessions created before the regression keep working normally with the same desktop client running.

Affected tools in new sessions: device_list_dir, device_bash, device_stage_files, device_commit_files, project_memory_read/write, and filesystem operations against the connected folder. Connected folders show up in the Context panel (from cached config) but are not functionally linked.

Because old and new sessions run on the identical client and only the new ones fail, the client version is ruled out. Capability-negotiation flags on the session (observed: manta=off shrimp=on) appear to gate tool provisioning server-side. This looks like a backend capability-gate rollout that grandfathers old sessions but denies the device-tool capability to newly created ones.

What Should Happen?

Newly created sessions get the device bridge tools provisioned exactly like pre-existing sessions, as long as the desktop app is running and a folder is connected.

Error Messages/Logs

Calling any device bridge tool in a new session returns:
No such tool available

--doctor: all checks pass.

Steps to Reproduce

1. Keep the desktop app running with at least one connected folder.
2. Open an existing Cowork session created before ~July 7, 2026 -> device tools work.
3. Create a new Cowork/Home session.
4. Call any device bridge tool (e.g. device_list_dir on the connected folder).
5. It returns "No such tool available", although the session context advertises the device as reachable.

Note: not specific to the Fedora repack; the failing path is server-side capability negotiation, so it likely affects any client whose new sessions land on the gated rollout. Related Fedora-repack reference: https://github.com/patrickjaja/claude-desktop-bin/issues/186

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Not a client-version regression: the same desktop client still works for pre-existing sessions. The regression is server-side and correlates with the ~July 7, 2026 Home merge.

Claude Code Version

2.1.205 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_