Claude Code connect silent failure

[Midway65]

Developer Report — Claude Code Provider Failure (v5.4.0)

Plugin: Nexus MCP for Obsidian
Version: v5.4.1
OS: Windows 11
Date: 2026-03-24
Reporter: Midway65
Severity: Critical — Claude Code provider completely unusable on Windows without manual workaround

---

Executive Summary

The Claude Code provider in Nexus Chat v5.4.1 fails silently on Windows for any user who has files listed in defaultContextNotes. The plugin injects the full text content of those files into the claude CLI spawn call via command-line arguments. Windows imposes a hard 32,767-character limit on process command lines (CreateProcess). Any non-trivial context file exceeds this limit immediately, causing every message to hang without any user-visible error.

The Anthropic API provider is unaffected because it transmits context in the HTTP request body, not via argv.

---

Chronology of Discovery

1. User configured Nexus Chat with defaultContextNotes containing three files.
   2. User authenticated Claude Code via claude auth login — succeeded in terminal.
2. User switched Nexus Chat to Claude Code provider — every message hung indefinitely with no error shown in the UI.
3. Removing the Anthropic API key had no effect (expected — the two providers use independent credential systems).
4. Obsidian Developer Console (Ctrl+Shift+I) revealed:

Error in generateResponse: Error: spawn ENAMETOOLONG
    at ChildProcess.spawn (node:internal/child_process:420:11)
    at Object.spawn (node:child_process:801:9)
    at spawnDesktopProcess (plugin:nexus:17747:23)
    at AnthropicClaudeCodeAdapter.generateStreamAsync (plugin:nexus:17926:25)

6. Direct spawn test in Developer Console confirmed claude.exe was reachable and functional:

require('child_process').exec(
  'claude -p "hello" --output-format text',
  (err, stdout, stderr) => { console.log('err:', err?.message, 'stdout:', stdout, 'stderr:', stderr) }
)
// Result: err: undefined, stdout: "Hello! How can I help you today?"
// stderr: "Warning: no stdin data received in 3s..."

7. Inspecting data.json revealed defaultContextNotes contained the large rules file — confirmed as the payload source.
8. Fix: Cleared defaultContextNotes to [] via Obsidian Settings → Nexus. Claude Code provider worked immediately on next test.

---

Root Cause

AnthropicClaudeCodeAdapter.generateStreamAsync (line ~17926) constructs a claude CLI spawn call and passes context — including the full text of all defaultContextNotes files — as command-line arguments via argv. On Windows, CreateProcess enforces a hard limit of 32,767 characters for the entire command line. A single large context file exceeds this before any conversation history is added.

The failure is silent in the UI. The spawn ENAMETOOLONG error is caught internally but not surfaced to the user. The chat simply hangs indefinitely, which makes diagnosis extremely difficult without knowing to open the Developer Console.

---

Secondary Finding: stdin Warning

The direct spawn test also revealed:

Warning: no stdin data received in 3s, proceeding without it.

The claude CLI expects stdin to be explicitly closed or redirected when not piping input. The plugin does not appear to pass stdio: ['ignore', 'pipe', 'pipe'] (or equivalent) in the spawn options, causing the CLI to stall for 3 seconds on every call waiting for stdin. This is a latency issue independent of ENAMETOOLONG — it adds ~3 seconds to every Claude Code response even when the argv limit is not exceeded.

---

Additional Console Finding: data.json Parse Error

The following error appeared in the Developer Console on Obsidian load:

failed to read JSON .obsidian/plugins/nexus/data.json
SyntaxError: Expected double-quoted property name in JSON at position 3704 (line 28 column 9)

This appeared to be transient (the file was valid when inspected manually) and may have occurred during a write operation earlier in the session. However, if data.json fails to parse on load, provider configuration including claudePath will not load correctly, which could contribute to Claude Code provider failures independently of the ENAMETOOLONG issue. The plugin should handle data.json parse failures gracefully and surface a clear error rather than silently falling back to defaults.

---

Impact

Scenario	Impact
User has any large file in defaultContextNotes	Claude Code provider completely non-functional on Windows
User has small/no context notes	Claude Code may work but stdin latency adds ~3s per message
data.json parse failure on load	Provider config silently reverts to defaults; Claude Code may appear unconfigured
Failure with no UI feedback	User has no path to diagnosis without knowing to open Developer Console

---

Recommended Fixes

Fix 1 — Pass context via stdin, not argv (Critical)

Rewrite AnthropicClaudeCodeAdapter.generateStreamAsync to pipe conversation context and defaultContextNotes content to the claude process via stdin rather than constructing a long argv string. This removes the Windows 32,767-char limit entirely.

// Current approach (problematic)
spawn('claude', [...contextArgs, ...historyArgs], { ... })
// Recommended approach

const proc = spawn('claude', ['--output-format', 'stream-json'], {

stdio: ['pipe', 'pipe', 'pipe']  // explicitly control all three streams

})

proc.stdin.write(JSON.stringify(contextPayload))

proc.stdin.end()

Fix 2 — Close stdin explicitly on spawn (High)

Even if context is not passed via stdin, always set stdin to 'ignore' when no stdin input is needed:

spawn('claude', args, {
  stdio: ['ignore', 'pipe', 'pipe']  // prevents 3s stdin wait
})

This eliminates the no stdin data received in 3s warning and removes the latency it causes.

Fix 3 — Enforce a context size budget with user warning (High)

If argv-based context injection is retained for any reason, enforce a maximum character budget before spawning and warn the user when files are truncated or excluded:

const MAX_ARGV_CHARS = 20000  // conservative budget below 32,767
if (totalContextLength > MAX_ARGV_CHARS) {
  // truncate and notify, or exclude defaultContextNotes
  showNotice('Context too large for Claude Code provider — defaultContextNotes excluded')
}

Fix 4 — Surface ENAMETOOLONG as a user-visible error (High)

Currently the spawn error is swallowed and the UI hangs silently. At minimum, catch ENAMETOOLONG specifically and display a clear message:

"Message too long for Claude Code provider. 
 Start a new chat, reduce context notes, or switch to the API provider."

Fix 5 — Validate data.json on load with fallback UI (Medium)

If data.json fails to parse, display a settings warning rather than silently loading defaults. A corrupted config that resets provider settings is a confusing failure mode.

Fix 6 — Document defaultContextNotes size constraint (Low)

Until the above fixes are implemented, add a note in the UI next to the defaultContextNotes setting:

"Note: Large context files may cause failures with the Claude Code provider on Windows 
 due to OS command-line length limits. Recommend keeping total context under 20KB."

---

Workaround (Current)

Clear defaultContextNotes in Obsidian Settings → Nexus → Default Context Notes. Remove all entries. The Claude Code provider will then function correctly. Context can be loaded per-session via the prompt selector or via MCP tool calls within the conversation.

---

Environment

Obsidian: 1.12.2
Nexus: v5.4.0
OS: Windows 11
Node (Electron internal): Chromium-bundled
Claude CLI: (authorized, functional)

---

[ProfSynapse]

Working on it! Might be a minute though this uncovered a few other issues

[ProfSynapse]

Hey @Midway65 — great bug report, and this is fixed in v5.5.0 (just released).

Your recommendations drove the fix directly:

Your Recommendation	What shipped in v5.5.0
Fix 1 — Pass context via stdin	✅ AnthropicClaudeCodeAdapter now pipes the full prompt via stdin (stdio: ['pipe','pipe','pipe']); argv is no longer used for context content
Fix 2 — Close stdin explicitly	✅ The old 'ignore' stdin is replaced with an explicit stdin.write(prompt) + stdin.end() — the 3s wait is gone
Fix 3 — Enforce a size budget	✅ assertSafeWindowsArgv throws early with a clear error if combined argv exceeds 24,000 chars
Fix 4 — Surface ENAMETOOLONG as a user-visible error	✅ errorCode is now propagated through cliProcessRunner → getUserVisibleErrorMessage → chat UI

Please update to v5.5.0 and let us know if the issue is resolved. Download main.js, connector.js, manifest.json, and styles.css from the v5.5.0 release and drop them in .obsidian/plugins/nexus/.

Thanks again for the thorough writeup — the reproducible steps and root cause analysis made this a clean fix.

[Midway65]

Bug Report — v5.5.0: Conversation History Still Hitting argv

Status

Follow-up to v5.4.0 report.

---

Report

Hi — thanks for the fast turnaround on v5.5.0. The stdin fix resolves the startup failure, but there's a regression: the chat now starts successfully but fails at turn 2–4 with the same assertSafeWindowsArgv error.

Environment

• Plugin: v5.5.0
• Provider: Claude Code (local)
• OS: Windows
• System prompt: nexus-chat-system-prompt (saved prompt, ~4,500 chars — well under the 24KB limit)

Observed behavior

Chat initialises and the first response completes. By turn 2–4, the following error appears in the Obsidian developer console and the chat stops responding:

plugin:nexus:70503 Error in generateResponse: LLMProviderError: Claude Code could not start because the appended system prompt is too large for Windows command-line limits. Reduce attached context files or shorten the system prompt and try again.
    at AnthropicClaudeCodeAdapter.assertSafeWindowsArgv (plugin:nexus:18448:17)
    at AnthropicClaudeCodeAdapter.generateStreamAsync (plugin:nexus:18163:16)
    at async StreamingOrchestrator.generateResponseStream (plugin:nexus:20383:30)
    at async LLMService.generateResponseStream (plugin:nexus:20786:9)
    at async StreamingResponseService.generateResponse (plugin:nexus:70420:28)
    at async ChatService.generateResponseStreaming (plugin:nexus:70743:9)
    at async MessageStreamHandler.streamResponse (plugin:nexus:79381:26)
    at async MessageStreamHandler.streamAndSave (plugin:nexus:79487:24)
    at async eval (plugin:nexus:79759:34)
    at async MessageManager.trackGeneration (plugin:nexus:79932:11)

Root cause hypothesis

The system prompt (~4,500 chars) is far below the 24KB threshold, so the initial assertSafeWindowsArgv check passes. However, as conversation history accumulates (prior turns + any tool results), it appears to be serialized onto argv rather than piped via stdin. By turn 2–4, cumulative history crosses 24KB and the guard fires.

The v5.5.0 fix moved the system prompt to stdin, but conversation history serialization does not appear to have been updated to match.

Expected behavior

Full conversation history (all prior turns and tool results) should be piped via stdin alongside the system prompt — not passed via argv. The assertSafeWindowsArgv check should either cover the full argv payload including history, or history should be excluded from argv entirely.

To reproduce

1. Install v5.5.0
2. Open Nexus Chat, select any saved system prompt (~4K+ chars)
3. Send 2–3 turns; include at least one tool call if possible
4. Fails by turn 4 or 5

---

Notes

• Switching to Anthropic API provider works fine for 10+ turns — confirms issue is argv serialization specific to Claude Code provider
• Prior report: 02-Projects/Nexus/_notes/bug-report-v5.4.0-claude-code-provider.md

---

Additional Console Findings (same session)

Two lower-priority issues observed in the same developer console output, both Nexus-owned.

1. Update checker returning 403

plugin:nexus:133895 Failed to check for updates: Error: Failed to fetch release info: Request failed, status 403
    at _UpdateManager.fetchLatestRelease (plugin:nexus:133993:11)
    at async _UpdateManager.checkForUpdate (plugin:nexus:133890:23)
plugin:nexus:134071 Failed to check for updates: Error: Failed to check for updates: Failed to fetch release info: Request failed, status 403

The update checker (_UpdateManager) is receiving a 403 on startup. Likely cause: unauthenticated GitHub releases API requests being rate-limited, or the endpoint URL has changed. Not breaking, but the failure is silent to the user — no in-app notification that update checking failed. Worth verifying the releases endpoint and whether an auth token or etag caching would help.

2. iframe sandbox security warning

354944be-794c-491d-9abb-3d5b8c4edd67:1 An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing.

The iframe used to sandbox transformers.js has both allow-scripts and allow-same-origin set simultaneously. This combination is a known sandbox escape vector — allow-same-origin allows the iframe to access its parent origin's storage and DOM, negating the isolation that allow-scripts is meant to enforce. Not exploitable in the Obsidian desktop context (Electron), but it will flag in any browser security audit and is a best-practice violation. If the iframe doesn't require same-origin access, removing allow-same-origin from the sandbox attribute would close it.

[ProfSynapse]

Follow-up patch v5.5.1 just shipped with one more fix for this:

The system prompt was still being passed inline on the command line even after v5.5.0. With a large workspace, a long system prompt could still push argv over the 32,767-char limit. v5.5.1 writes the system prompt to a temp file and passes the path via --append-system-prompt-file instead, so it no longer contributes to argv length at all.

Update to v5.5.1 and let us know if you're still seeing issues!

[Midway65]

Asked Claude code to stress test it from within Nexus Chat yielding this result. In general it ran smoothly although slowly during the test.

Bug Report — v5.5.1: -p prompt still in argv — assertSafeWindowsArgv fires at same turn threshold

Follow-up to the v5.5.0 regression report.

Summary

The v5.5.1 fix is incomplete. writePromptToStdin was added and --append-system-prompt-file is implemented correctly, but "-p", prompt was not removed from the args array. The full conversation history is still passed on the command line, so assertSafeWindowsArgv fires at the same turn threshold as before.

Evidence — source inspection of v5.5.1 main.js (offset 640998)

const args = [
  runtime.claudePath,
  "-p",
  prompt,              // ← full serialized conversation history still in argv
  "--mcp-config",
  mcpConfigPath,
  "--no-session-persistence",
  "--dangerously-skip-permissions",
  "--output-format",
  "stream-json"
];
// ...
this.assertSafeWindowsArgv(runtime.claudePath, args);  // fires before spawn
// ...
await this.writePromptToStdin(child, prompt);           // never reached when guard fires

assertSafeWindowsArgv measures [claudePath, ...args].join(" ").length, which includes -p <full prompt>. As conversation history accumulates across turns, this crosses 24,000 chars and the guard throws — before the process spawns, making writePromptToStdin unreachable.

What v5.5.1 changed vs. what it missed

Item	v5.5.1 status
System prompt → --append-system-prompt-file	✅ Fixed
writePromptToStdin added	✅ Added
"-p", prompt removed from args	❌ Not done

Fix

Remove "-p", prompt, from the args array. writePromptToStdin already delivers the prompt via stdin — -p is redundant and is what causes the overflow.

To reproduce

1. Install v5.5.1, select any saved system prompt
2. Send 3–5 turns
3. Developer Console: assertSafeWindowsArgv: Claude Code could not start because the appended system prompt is too large...

Environment: Plugin v5.5.1 · Windows 11 · Claude Code provider

---