Remote Control fails to enable on sessions with a large transcript ("Session creation failed — see debug log")

Status Fixed / completed
Reported on v2.1.209
Maintainer reply None cached
Activity 0 comments · opened Jul 18, 2026 · closed Aug 7, 2026

Remote Control fails to enable on sessions with a large transcript ("Session creation failed — see debug log")

Environment

  • Claude desktop app (Windows), CCD build 2.1.209 (staged app.asar 1.22209.0)
  • Bundled Claude Code CLI: claude-code\2.1.209\claude.exe

Summary

Enabling Remote Control on a session whose transcript JSONL is roughly 10 MB or larger consistently fails with the generic toast/log message:

Session creation failed — see debug log

Smaller sessions (under ~1 MB) enable successfully every time. This looks like a payload-size limit on the session-creation request rather than an auth/network issue.

Root cause (from binary inspection)

Disassembling the bundled CLI (claude-code\2.1.209\claude.exe), the remote-control "create session" path does:

R = { title, events: r, session_context: {...}, source: "remote-control", ... }
P = `${BASE_API_URL}/v1/sessions`
L = await _.post(P, R, { validateStatus: (D) => D < 500 })
if (!(L.status === 200 || L.status === 201)) {
  w(`[bridge] Session creation failed with status ${L.status}...`)
  return null
}

events: r embeds the full transcript event history in the POST body. For large sessions this request appears to be rejected (likely a body-size limit), and the caller falls through to the generic UI string:

function Se(Rt){
  if (Rt && xe !== void 0) { ... }
  return "Session creation failed — see debug log"
}

The "see debug log" is misleading

The actual failure reason (w(...), i.e. the CLI's internal debug logger) is never written to any file the desktop app persists — main.log, claude.ai-web.log, unknown-window.log, etc. all just show:

[remote-control] bridge_state: failed — Session creation failed — see debug log
[error] Failed to toggle remote control for local_<id>: Session creation failed — see debug log

There is no debug log a user can actually open to see the real HTTP status/reason. This makes the failure unactionable from the UI.

Repro / evidence

Measured transcript size (.claude\projects\...\<cliSessionId>.jsonl) vs. Remote Control enable outcome, same machine/account, same day:

| Transcript size | Enable result |
|---|---|
| 10.9 MB | ❌ fails immediately (~2s) with the message above |
| 9.9 MB | ❌ fails immediately (~2s) with the message above |
| 0.86 MB | ✅ succeeds (tested live) |
| 0.1–0.5 MB | ✅ succeeds (multiple sessions) |

Across ~2 weeks of main*.log history, every "Session creation failed — see debug log" failure correlates with a large transcript; every large (>5MB) live session currently fails to enable. Sessions that re-enabled successfully after being idle for hours were all small transcripts.

Expected behavior

  • Either don't send the full transcript on every remote-control enable (e.g. only recent context, or a summarized/truncated payload), or
  • Surface the actual server error/status to the user instead of a generic unactionable message, and
  • Write the CLI's internal error output somewhere the desktop app's log bundle actually includes, so "see debug log" refers to something real.

Workaround

Start a new session (or otherwise keep the transcript small) before enabling Remote Control. Existing long-running sessions with large transcripts cannot currently use Remote Control at all.

View original on GitHub ↗