Remote Control (`/rc`) stuck on "connecting…" — bridge sends `source` field rejected by `ccr-byoc` session-create schema (400)

Summary

claude remote-control (and the /rc slash command) never finishes connecting. The bridge environment registers successfully, but the pre-created session that the interactive UI waits on fails with HTTP 400, so the CLI sits at "connecting…" forever.

Root cause: the bridge's create-session request to POST /v1/sessions (beta ccr-byoc-2025-07-29) includes a top-level source: "remote-control" field that the only existing ccr-byoc schema does not define. Because that schema is extra = "forbid", the request is rejected:

400 invalid_request_error: "source: Extra inputs are not permitted"

The field is hard-coded (no env var / flag suppresses it), and the behavior is identical across 2.1.153 (stable), 2.1.174, and 2.1.178 (latest).

Environment

| | |
|---|---|
| Claude Code | 2.1.153 / 2.1.174 / 2.1.178 — all reproduce (native install) |
| Platform | macOS (darwin arm64) |
| Auth | claude.ai OAuth, Team tier, scope user:sessions:claude_code present |
| Endpoint | POST https://api.anthropic.com/v1/sessions?beta=true |
| Beta header | anthropic-beta: ccr-byoc-2025-07-29 |

(Org UUID withheld here for privacy — it can be derived from the request IDs below.)

Steps to reproduce

1. claude auth login with a claude.ai Team account.
2. Run claude remote-control (or /rc in a session).
3. UI stays on "connecting…" and never reaches "connected".

Capture the failure with:

claude remote-control --debug-file /tmp/rc.log --verbose --spawn=session

Debug log (the smoking gun)

[bridge:api] POST /v1/environments/bridge -> 200 environment_id=env_…       ← environment OK
[bridge] Session creation failed with status 400: source: Extra inputs are not permitted   ← FAILS
[bridge:work] Starting poll loop spawnMode=single-session maxSessions=1 …
[bridge:api] GET .../work/poll -> 200 (no work, 1 consecutive empty polls)

The environment registers, but no session is created → nothing for the UI to attach to → permanent "connecting…".

Client payload (decompiled from the bridge create-session code)

// POST /v1/sessions?beta=true ; headers: anthropic-beta: ccr-byoc-2025-07-29, x-organization-uuid: <org>
{
  "title": "<machine-name>",            // optional
  "events": [],
  "session_context": {                  // matches the ccr-byoc schema (required)
    "sources": [...], "outcomes": [...], "model": "<model>", "cwd": "<dir>",
    "reuse_outcome_branches": true
  },
  "source": "remote-control",           // ← hard-coded; NOT in the schema → 400
  "permission_mode": "…",               // optional
  "tags": [...]                         // optional
}

Evidence — direct probes against the endpoint (validation-only, no resources created)

| Beta header | Body | Server response |
|---|---|---|
| ccr-byoc-2025-07-29 | {} | 400 session_context: Field required — schema healthy & reachable |
| ccr-byoc-2025-07-29 | {"source":"remote-control"} | 400 source: Extra inputs are not permitted |
| ccr-byoc-2025-07-29 | {"session_context":{},"source":"x"} | 400 source: Extra inputs are not permitted (rejected even with valid context) |
| managed-agents-2026-04-01 | {} | 400 agent: Field required (different schema) |
| managed-agents-2026-04-01 | {"source":"…"} | 400 source: Extra inputs are not permitted. Did you mean 'resources'? |

ccr-byoc version check — 2025-07-29 is the only schema that exists:

| Beta header | Server response |
|---|---|
| ccr-byoc-2025-07-29 | valid (schema served) |
| ccr-byoc-2025-10-01, -2026-01-01, -2026-04-01, bare ccr-byoc | no schema found for anthropic-beta header value: … |

So the bridge targets the correct (and only) ccr-byoc schema — the beta header is not mismatched. The sole problem is the extra source field.

Relevant request IDs (Anthropic can map these to the org & full traces):

• req_011Cc7918ye7nxbmvc2KrSzB (empty body → session_context required)
• req_011Cc791BBbS2LehV7pLxMUk (source-only body → source rejected)

Likely mechanism (hypothesis)

The client has always sent source: "remote-control". The ccr-byoc-2025-07-29 create-session schema was likely previously extra = "ignore" (silently dropping unknown fields), and a recent backend deploy flipped it to extra = "forbid", which began rejecting the always-present source. This fits both "client/server contract mismatch" and "appears to have broken recently."

Expected vs actual

• Expected: POST /v1/sessions succeeds, the pre-created session comes up, /rc reaches "connected".
• Actual: 400 source: Extra inputs are not permitted; no session; permanent "connecting…".

Suggested fix (either side resolves it)

1. Client: stop sending the top-level source field in the ccr-byoc create-session request (or move it under a field the schema defines).
2. Backend: add source to the ccr-byoc-2025-07-29 create-session schema, or revert that schema to ignore unknown fields.

Ruled out (with evidence)

• Auth — token valid, correct scope user:sessions:claude_code.
• Network — api.anthropic.com and bridge.claudeusercontent.com both reachable; WS host correctly demands an upgrade.
• Client version — 2.1.153 / 2.1.174 / 2.1.178 all produce the identical 400.
• Org policy / device attestation — those return 403 / explicit messages; this is a 400 schema-validation error that never reaches those gates.

Open question

Diagnosed from a single account/org, so I could not confirm whether other orgs also reject source. Because ccr-byoc-2025-07-29 is the only schema version and it is the one rejecting source, the evidence leans toward a global client over-send rather than a stale per-org backend — but that last point is inference, not confirmed.