[BUG] Claude Projects: every cloud thread is server-side bound to the desktop device (config:claude-code-device-bind), which blocks egress writes and Google OAuth refresh; only fix ("Require trusted devices") disables project Remote Control

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?

Summary

On a Pro/Max account that has the Claude desktop app registered as a device, every new cloud thread session in Claude Projects is bound server-side to that desktop device, without the thread or the user asking for it. Once bound, the egress proxy puts the session in a restricted mode: POST/PATCH to most hosts (all Google API hosts, S3) is refused with a 403 that says network access is "limited because it has been connected to your computer".

Because a Google OAuth token refresh is a POST to oauth2.googleapis.com/token, a bound cloud thread cannot refresh tokens, so it can neither read nor write Google Docs / Sheets / Drive / Gmail. Our whole workflow (a blog pipeline that runs in project cloud threads and writes to Google Docs and Sheets via the gws CLI) stops.

The binding happens:

• with no approved folders for the project,
• with the project's default device cleared,
• with the desktop app quit on every machine (get_device_info reports the device "not connected to the bridge", yet the thread is still bound),
• in a second, unrelated project on the same account.

The only switch we found that stops it is the account setting Require trusted devices. With it on, cloud threads are no longer bound and Google works, but start_rc_session from a project is then refused: "Remote Control sessions from a Project aren't supported with that yet". So today a user must choose between Google-capable project cloud threads and project Remote Control sessions on their PC. They can't have both.

Detail

Step 5 (setting OFF): the thread is bound without asking.

• About 30 s after the thread starts, a server "late-bind" step adds the remote-devices MCP host to the session. The thread suddenly gets mcp__remote-devices__* tools lent by the desktop app: computer use (~28 tools), folder tools (6), desktop artifacts (4), local plugin tools, get_device_info.
• The session record carries the tag config:claude-code-device-bind, device_bind_posture: {bind: "attested", surface: "claude_code"}, and a bound_device (the desktop device's display name and id).
• The thread shows a notice that it has been connected to the computer.
• This happens with no approved folders, with the default device cleared, and with the desktop app quit (then get_device_info reports "not connected to the bridge", but the session is still bound to the same device id and still restricted). The bind follows the registered device record, not an online app, and it is account-wide (a second project with no approved folders was bound to the same device id).

Step 6 (setting OFF): egress is restricted for the bound session.

| Request from the bound cloud thread | Result |
|---|---|
| GET to any Google API host | allowed |
| POST/PATCH to oauth2, www, docs, sheets, drive, gmail, storage, compute .googleapis.com, and s3.amazonaws.com | 403 from the egress proxy: network access from this session is "limited because it has been connected to your computer" |
| POST to hosts that have an environment API credential (e.g. generativelanguage.googleapis.com, analyticsdata.googleapis.com, api.exa.ai), and GitHub, npm | allowed |

Since an OAuth refresh is a POST to oauth2.googleapis.com/token, every Google identity in the container fails with 401 once its access token expires, so in practice reads fail too.

Quitting the desktop app removes the remote-devices tools from an already-bound thread, but not the network restriction.

Failed workaround: environment API credential. We added an API credential on the Default environment covering the six Google hosts with a harmless custom header, to use the "credential hosts are exempt" behaviour. The proxy then let POST through (the token refresh reached Google). But on credential-covered hosts the proxy strips the client's own Authorization header: with a dummy bearer, www/sheets.googleapis.com (credential hosts) answered "missing required authentication credential", while youtube/people.googleapis.com (no credential) answered "invalid authentication credentials" (header arrived). So every Docs/Sheets/Drive call arrived unauthenticated and per-user OAuth can't go through a credential host. We removed the credential. (Stripping a client header on credential hosts may be intentional, but it isn't documented on https://code.claude.com/docs/en/cloud-environments#add-api-credentials.)

Step 7 (Require trusted devices ON): the binding is gone. Fresh thread: no bound_device, no device_bind_posture, no config:claude-code-device-bind tag, no remote-devices tools, no "connected to your computer" notice. POST to oauth2.googleapis.com/token reaches Google; Sheets read and Doc create/write/delete all work.

Step 8 (Require trusted devices ON): project Remote Control is refused. start_rc_session returns "Remote Control sessions from a Project aren't supported with that yet; nothing reached a device". Turning the setting off again restores Remote Control, and every cloud thread started while it is off is bound again.

Impact

A user who uses Claude Projects for both cloud work that writes to an external API (Google here, but the same applies to any host the bound mode blocks for POST) and Remote Control jobs on their PC has to toggle an account security setting back and forth. Cloud threads that start while it's off are silently crippled, and the only signal is a proxy 403 deep inside a tool call.

What Should Happen?

• A project cloud thread stays a plain cloud session unless the user asks for it to run on, or reach, their computer (the docs describe this as an explicit Work locally / Allow card through Remote Control: https://code.claude.com/docs/en/claude-projects#run-a-thread-on-your-own-computer).
• Its egress follows the cloud environment's network access setting. Nothing in the cloud-environments docs mentions a stricter mode when a session is "connected to your computer".
• If binding to a device is intended, there is a visible per-project or per-thread way to opt out that does not also turn off Remote Control.
• Require trusted devices adds attestation to Remote Control; it does not make project Remote Control unavailable.

What would fix it (any one):

1. Don't bind project cloud threads to a device unless the user picks "Work locally" / allows the device for that thread, or unless the project has approved folders on it.
2. Or keep the bind (so the thread can use the desktop's tools) but don't apply the "connected to your computer" egress restriction to hosts the cloud environment already allows.
3. Or give a per-project / per-environment setting to opt cloud threads out of the device bind.
4. And support project Remote Control with Require trusted devices on (the message says "yet").
5. Document the bound-session egress mode and the Authorization stripping on API-credential hosts.

Error Messages/Logs

egress proxy 403 (bound cloud thread, POST to oauth2.googleapis.com/token and other Google API hosts):
  network access from this session is limited because it has been connected to your computer

start_rc_session from a project with "Require trusted devices" ON:
  Remote Control sessions from a Project aren't supported with that yet; nothing reached a device

Session record of a bound cloud thread (ids redacted):
  tags: [..., "config:claude-code-device-bind"]
  device_bind_posture: {"bind": "attested", "surface": "claude_code"}
  bound_device: {display_name: "<desktop device>", id: "<redacted>"}

get_device_info from a bound thread with the desktop app quit:
  not connected to the bridge

Steps to Reproduce

1. On a Pro/Max account, install the Claude desktop app on a PC and sign in, so the PC is registered as a device. Leave Require trusted devices OFF.
2. Create a Claude Project with a repository, using a cloud environment with network access that allows the Google API hosts (oauth2.googleapis.com, www.googleapis.com, docs.googleapis.com, sheets.googleapis.com, drive.googleapis.com, gmail.googleapis.com).
3. Optional, to rule out the obvious triggers: remove all approved PC folders from the project, clear the project's default device, and quit the desktop app on every machine.
4. In the project chat, ask for something so the coordinator starts a new thread session (cloud).
5. About 30 seconds after the thread starts, check the session (e.g. get_session from the claude-code-remote MCP server, and the thread's tool list).
6. From the thread, run curl -X POST https://oauth2.googleapis.com/token -d 'grant_type=refresh_token&...' (or any Google CLI that refreshes a token), and a GET to the same host for comparison.
7. Turn Require trusted devices ON, start another fresh thread, and repeat steps 5 and 6.
8. With the setting still ON, have the coordinator call start_rc_session for an approved folder on the PC.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.289 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Non-interactive/CI environment

Additional Information

Environment

• Claude Code 2.1.289 (in the cloud thread containers)
• Claude desktop app 2.19675.0 (Electron 44.4.3), Windows, signed in on the same account
• Surface: Claude Projects (claude.ai/code/project/...), one coordinator (channel) session + thread sessions, run in the account's Default cloud environment (custom network access)
• Plan: individual Pro/Max account (not Team/Enterprise)
• The same account also uses Remote Control (start_rc_session from the project, served from a folder on the desktop PC)
• First seen 4 Oct 2026; reproduced repeatedly on 5 Oct 2026

Related issues

• #93512: Cowork cloud sessions "linked to local computer" hit proxy 403s, including a Google token refresh that "never left the proxy". Very likely the same root cause (the device link), seen from Cowork rather than Projects.
• #78671: the opposite case (cloud Cowork sessions provisioned without remote-devices despite an authenticated bridge). It shows the bind is a client/server handshake (signCreateSessionBind, "proceeding unbound").
• #92885 (asks for a visible per-project Local/Remote execution setting in Cowork, the same opt-out this report needs).
• #99463 (server-side device posture on sessions), #90265 (trusted devices on individual accounts), #95671 / #93561 / #95908 / #94640 (other egress-proxy 403s in cloud sessions).

Session ids, environment id, device id and timestamps for every test above can be shared privately with the Anthropic team on request.