[BUG] Dispatch transport:sdk hardcoded 10s timeout incompatible with power-user plugin/skill loads (macOS)

Preflight Checklist

• [x] I have searched existing issues — most-relevant prior reports linked at the bottom
• [x] This is a single bug report
• [x] 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:

| Configuration | Cold-start | Under 10 s? |
|---|---:|:---:|
| 33 plugins enabled, bundled claude-code 2.1.111, isUsingBuiltInNodeForMcp:false | 93 s | ❌ |
| 33 plugins enabled, bundled 2.1.119, isUsingBuiltInNodeForMcp:false | 41 s | ❌ |
| 33 plugins enabled, bundled 2.1.119, isUsingBuiltInNodeForMcp:true | 24 s | ❌ |
| 0 user plugins enabled, bundled 2.1.119 | 16 s | ❌ |
| --setting-sources=local (no user-level config at all) | 5.5 s | ✅ |

Even with zero user-level plugins enabled in ~/.claude-config/settings.json → enabledPlugins, 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.