claude-code - 💡(How to fix) Fix [BUG] Dispatch transport:sdk hardcoded 10s timeout incompatible with power-user plugin/skill loads (macOS) [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#53266Fetched 2026-04-26 05:20:07
View on GitHub
Comments
0
Participants
1
Timeline
7
Reactions
0
Participants
Timeline (top)
labeled ×5cross-referenced ×2

Error Message

Error Messages/Logs

Root Cause

Likely related (same UI symptom, no root cause investigation in those threads):

  • #45937 — "Dispatch main conversation permanently offline despite working Cowork tasks"
  • #49545 — "Claude Dispatch permanently showing 'desktop appears offline' for multiple weeks" (labeled duplicate)
  • #48754 — "Cowork/Dispatch: backend drops env/session records …" — different root cause (server-side 503/404), but similar surface symptom

Fix Action

Fix / Workaround

TL;DR: the desktop's [transport:sdk] adapter has a hard-coded 10000 ms timeout when calling POST /worker/register (functions hqr and vVr in the bundled app.asar). On power-user accounts with many Code-marketplace plugins + bundled official skills, the SDK bootstrap routinely takes 20–90+ s, so every Dispatch session attempt fails. The user-facing UI shows "Desktop appears offline" / "Can't reach your desktop" forever.

  1. Make the registerWorker (and surrounding session-bridge) timeouts configurable, or raise the default to ≥60 s, or

  2. Provide a "Dispatch lite" execution mode that does not load the full set of user-level plugins / skills before registering, or

  3. Lazy-load bundled official skills and claude-plugins-official Code plugins so cold-start stays under a tighter bound regardless of plugin count.

  4. Use a Pro/Max account with many Code-marketplace plugins installed via the Claude Code CLI (claude /plugin install …). My account has the standard claude-plugins-official set (~33 plugins, including superpowers, vercel, supabase, playwright, huggingface-skills, pinecone, firebase, pyright-lsp, typescript-lsp, frontend-design, context7, etc.) plus the Anthropic Connectors suite.

  5. Toggle Dispatch on (Claude.app desktop), confirm onboarding from mobile.

  6. Send a message from the mobile Dispatch tab.

  7. Observe perpetual "Desktop appears offline" on desktop and "Can't reach your desktop" on mobile.

  8. Inspect ~/Library/Logs/Claude/main.log — see the transport:sdk … timeout of 10000ms exceeded retry loop.

Code Example

[transport:bridge] gate on — using SDK adapter for session <CSE_ID>
[transport:sdk] attaching SDK bridge session <CSE_ID> (apiBaseUrl=https://api.anthropic.com)
Failed to connect transport for session <CSE_ID>: timeout of 10000ms exceeded
[sessions-api] Stopping work <CSE_ID> force=true
… repeat every 1012 s indefinitely …

---

async function hqr(e, A) {
  let t = await cJt.post(`${e}/worker/register`, {}, {
    headers: { Authorization: `Bearer ${A}`, "Content-Type": "application/json", "anthropic-version": "2023-06-01" },
    timeout: 1e4   // ← hardcoded
  });
}

---

# main.log (sanitized)
[sessions-bridge] Initializing bridge { oauthEnv: 'production', apiHost: 'https://api.anthropic.com' }
[sessions-bridge] Registering environment (fresh)...
[sessions-api] POST /v1/environments/bridge
[sessions-bridge] Environment registered: <ENV_ID>
[sessions-bridge] Created session <SESSION_ID> (trigger=start)
[sessions-api] Poll received work: id=<CSE_ID> type=session sessionId=<CSE_ID>
[sessions-bridge] Handling session work { sessionId: '<CSE_ID>', workId: '<CSE_ID>' }
[sessions-bridge] Connecting transport for session <CSE_ID>
[transport:bridge] gate on — using SDK adapter for session <CSE_ID>
[transport:sdk] attaching SDK bridge session <CSE_ID> (apiBaseUrl=https://api.anthropic.com)
[CCD] Passing 47 plugin(s) to SDK (skills: 1, remote: 15, local: 31)
[sessions-bridge] Failed to connect transport for session <CSE_ID>: timeout of 10000ms exceeded
[sessions-api] Stopping work <CSE_ID> force=true
# loop repeats indefinitely, ~10–12s cadence
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues — most-relevant prior reports linked at the bottom
  • This is a single bug report
  • I am using the latest version of Claude Code

What's Wrong?

TL;DR: the desktop's [transport:sdk] adapter has a hard-coded 10000 ms timeout when calling POST /worker/register (functions hqr and vVr in the bundled app.asar). On power-user accounts with many Code-marketplace plugins + bundled official skills, the SDK bootstrap routinely takes 20–90+ s, so every Dispatch session attempt fails. The user-facing UI shows "Desktop appears offline" / "Can't reach your desktop" forever.

This is observable on main.log as a tight retry loop:

[transport:bridge] gate on — using SDK adapter for session <CSE_ID>
[transport:sdk] attaching SDK bridge session <CSE_ID> (apiBaseUrl=https://api.anthropic.com)
Failed to connect transport for session <CSE_ID>: timeout of 10000ms exceeded
[sessions-api] Stopping work <CSE_ID> force=true
… repeat every 10–12 s indefinitely …

The timeout of 10000ms exceeded message format is from axios, originating in the bundled hqr:

async function hqr(e, A) {
  let t = await cJt.post(`${e}/worker/register`, {}, {
    headers: { Authorization: `Bearer ${A}`, "Content-Type": "application/json", "anthropic-version": "2023-06-01" },
    timeout: 1e4   // ← hardcoded
  });
}

There is a parallel fetch-based path (vVr) that hardcodes the same 10000 ms via AbortController.

What Should Happen?

Either:

  1. Make the registerWorker (and surrounding session-bridge) timeouts configurable, or raise the default to ≥60 s, or
  2. Provide a "Dispatch lite" execution mode that does not load the full set of user-level plugins / skills before registering, or
  3. Lazy-load bundled official skills and claude-plugins-official Code plugins so cold-start stays under a tighter bound regardless of plugin count.

Error Messages/Logs

# main.log (sanitized)
[sessions-bridge] Initializing bridge { oauthEnv: 'production', apiHost: 'https://api.anthropic.com' }
[sessions-bridge] Registering environment (fresh)...
[sessions-api] POST /v1/environments/bridge
[sessions-bridge] Environment registered: <ENV_ID>
[sessions-bridge] Created session <SESSION_ID> (trigger=start)
[sessions-api] Poll received work: id=<CSE_ID> type=session sessionId=<CSE_ID>
[sessions-bridge] Handling session work { sessionId: '<CSE_ID>', workId: '<CSE_ID>' }
[sessions-bridge] Connecting transport for session <CSE_ID>
[transport:bridge] gate on — using SDK adapter for session <CSE_ID>
[transport:sdk] attaching SDK bridge session <CSE_ID> (apiBaseUrl=https://api.anthropic.com)
[CCD] Passing 47 plugin(s) to SDK (skills: 1, remote: 15, local: 31)
[sessions-bridge] Failed to connect transport for session <CSE_ID>: timeout of 10000ms exceeded
[sessions-api] Stopping work <CSE_ID> force=true
# loop repeats indefinitely, ~10–12s cadence

Steps to Reproduce

  1. Use a Pro/Max account with many Code-marketplace plugins installed via the Claude Code CLI (claude /plugin install …). My account has the standard claude-plugins-official set (~33 plugins, including superpowers, vercel, supabase, playwright, huggingface-skills, pinecone, firebase, pyright-lsp, typescript-lsp, frontend-design, context7, etc.) plus the Anthropic Connectors suite.
  2. Toggle Dispatch on (Claude.app desktop), confirm onboarding from mobile.
  3. Send a message from the mobile Dispatch tab.
  4. Observe perpetual "Desktop appears offline" on desktop and "Can't reach your desktop" on mobile.
  5. Inspect ~/Library/Logs/Claude/main.log — see the transport:sdk … timeout of 10000ms exceeded retry loop.

Empirical evidence — cold-start vs the 10 s limit

Measured time claude -p "hi" --max-turns 1 against the bundled binary at ~/Library/Application Support/Claude/claude-code/<ver>/claude.app/Contents/MacOS/claude:

ConfigurationCold-startUnder 10 s?
33 plugins enabled, bundled claude-code 2.1.111, isUsingBuiltInNodeForMcp:false93 s
33 plugins enabled, bundled 2.1.119, isUsingBuiltInNodeForMcp:false41 s
33 plugins enabled, bundled 2.1.119, isUsingBuiltInNodeForMcp:true24 s
0 user plugins enabled, bundled 2.1.11916 s
--setting-sources=local (no user-level config at all)5.5 s

Even with zero user-level plugins enabled in ~/.claude-config/settings.jsonenabledPlugins, the bundled official skills (47 in the skills-plugin manifest: doc-coauthoring, web-artifacts-builder, skill-creator, theme-factory, mcp-builder, pdf, pptx, docx, xlsx, internal-comms, brand-guidelines, schedule, consolidate-memory, canvas-design, algorithmic-art, setup-cowork, …) push baseline cold-start above 10 s. So no end-user configuration tweak can fix this as long as the official skill set is bundled and the timeout stays at 10 s.

Things tried (none worked)

  • Cmd+Q + reopen, multiple times
  • Toggled Dispatch off → wait → on
  • Wiped ~/Library/Application Support/Claude/bridge-state.json, let app re-register a fresh session/environment (logs confirm fresh registration succeeds, then the same transport timeout)
  • Force-deleted ~/Library/Application Support/Claude/claude-code/2.1.111/, app re-downloaded 2.1.119 on next launch — helped (-56 %) but not enough
  • Set isUsingBuiltInNodeForMcp:true in claude_desktop_config.json — helped (-41 % more) but not enough
  • Disabled all 33 plugins via enabledPlugins — still 16 s baseline (above the 10 s cap)
  • Patched the two 1e4 literals in app.asar (hqr and vVr) to 1e5 — works conceptually but macOS code-signing rejects any app.asar modification ("Claude quit unexpectedly" on launch). Restored from backup.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

For me, Dispatch has never worked — earliest entry in main.log is the same 10 s loop. Other users in #45937 / #49545 report it worked previously.

Claude Code Version

CLI: 2.1.118 (Claude Code). Claude.app desktop: 1.3883.0 (after auto-update). Bundled claude-code inside the app (used by Dispatch/SDK adapter): 2.1.119 (after forcing a re-download).

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Likely related (same UI symptom, no root cause investigation in those threads):

  • #45937 — "Dispatch main conversation permanently offline despite working Cowork tasks"
  • #49545 — "Claude Dispatch permanently showing 'desktop appears offline' for multiple weeks" (labeled duplicate)
  • #48754 — "Cowork/Dispatch: backend drops env/session records …" — different root cause (server-side 503/404), but similar surface symptom

Specific code locations (bundled app.asar from Claude.app 1.3883.0):

  • hqr (axios POST /worker/register, timeout: 1e4)
  • vVr (fetch POST /worker/register, setTimeout(()=>r.abort(), 1e4))
  • xVr is the SDK-adapter connect() that calls await fqr({...})await R8e({...})await hqr(...)

Suggested minimal fix: bump both 1e4 literals to 1e5 (or, better, plumb the timeout through a config / read it from claude_desktop_config.json). Patch is verifiably surgical (only ±16 bytes vs original app.asar size).

Why this isn't user-fixable today:

  • No UI to disable plugins per-context (Dispatch vs CLI vs VS Code).
  • No way to extend the timeout via env var or settings file.
  • app.asar patch is blocked by the macOS code-signing integrity check.

Logs are reproducible on demand; happy to provide main.log excerpts (further sanitized) on request.

extent analysis

TL;DR

Increase the hardcoded timeout in the hqr and vVr functions from 10 seconds to a higher value, such as 60 seconds, to accommodate the longer bootstrap times of power-user accounts with many plugins.

Guidance

  • Identify the hqr and vVr functions in the bundled app.asar and update the timeout value from 1e4 to a higher value, such as 6e4 (60 seconds).
  • Alternatively, consider making the timeout configurable through a settings file or environment variable to allow users to adjust the value based on their specific needs.
  • Verify that the updated timeout value resolves the issue by checking the main.log for the presence of the "timeout of 10000ms exceeded" error message.
  • If the issue persists, investigate other potential causes, such as network connectivity or server-side issues, to rule out other factors.

Example

async function hqr(e, A) {
  let t = await cJt.post(`${e}/worker/register`, {}, {
    headers: { Authorization: `Bearer ${A}`, "Content-Type": "application/json", "anthropic-version": "2023-06-01" },
    timeout: 6e4 // updated timeout value
  });
}

Notes

  • The suggested fix is based on the provided information and may not be the only possible solution.
  • The update to the app.asar file may be blocked by macOS code-signing integrity checks, requiring alternative approaches to implement the fix.
  • Further investigation may be necessary to determine the root cause of the issue and to identify other potential solutions.

Recommendation

Apply a workaround by increasing the hardcoded timeout value to a higher value, such as 60 seconds, to accommodate the longer bootstrap times of power-user accounts with many plugins. This change can be made by updating the hqr and

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Dispatch transport:sdk hardcoded 10s timeout incompatible with power-user plugin/skill loads (macOS) [1 participants]