Local MCP servers fail with 'spawn ENOENT' after version update — PATH not inherited on macOS #26356

Activity

1. github-actions

   assigned

   Brendonovich

   on May 8, 2026
2. github-actions commented on May 8, 2026

   

   github-actionsBot

   on May 8, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • OpenCode Desktop ignores path, while TUI doesn't #25748: OpenCode Desktop ignores path (npx, uvx not found), while TUI works correctly — same root cause of Desktop not inheriting shell PATH
   • [Desktop][macOS][MCP] bunx cannot be resolved for local MCP server (Executable not found in $PATH) #15565: [Desktop][macOS][MCP] bunx cannot be resolved for local MCP server — same PATH inheritance issue on macOS Desktop

   If your issue is the same, please add a "+1" or relevant details to those threads instead.
3. leoncheng57 commented on May 8, 2026

   

   leoncheng57

   on May 8, 2026

   Author

   More actions

   Update: absolute paths alone are insufficient

   Using absolute paths for the command (e.g., /opt/homebrew/bin/npx) fixes the initial spawn ENOENT, but the spawned process inherits the stripped PATH. So npx finds itself but then fails when it tries to spawn node as a child:

   env: node: No such file or directory
   

   This causes MCP error -32000: Connection closed for all npx-based servers.

   Full workaround requires both:

   1. Absolute path in command
   2. Explicit PATH in environment:

   "notion-work": {
     "type": "local",
     "command": ["/opt/homebrew/bin/npx", "-y", "@notionhq/notion-mcp-server"],
     "environment": {
       "PATH": "/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin",
       "NOTION_TOKEN": "..."
     },
     "enabled": true
   }

   This is a significant UX regression — previously neither was needed.
4. leoncheng57 commented on May 11, 2026

   

   leoncheng57

   on May 11, 2026

   Author

   More actions

   Possibly related: opencode mcp auth <name> fails with opaque "JSON Parse error" when mcp-auth.json is corrupted

   Hitting this on v1.14.41 (macOS). Different code path from the spawn-ENOENT issue above, but filing here since it's the active MCP-pain thread — happy to split into its own issue if preferred.

   Symptom

   $ opencode mcp auth gitlab-mcp
   ┌  MCP OAuth Authentication
   Error: Unexpected error, check log file at /Users/me/.local/share/opencode/log/2026-05-11T160949.log for more details
   
   JSON Parse error: Unable to parse JSON string
   

   The log file contains only the standard config-loading lines and stops before any actionable error — nothing identifies the offending file.

   Root cause
   ~/.local/share/opencode/mcp-auth.json was corrupted with a stray extra } at EOF:

   ...
     }
   }
   }   ← extra
   

   JSON.parse rejects this with Extra data (the underlying message that gets swallowed into the generic "Unable to parse JSON string"). Fix was to strip the trailing brace and re-serialize — opencode mcp auth then works.

   Two suggestions

   1. Surface the file path in the error. Wrapping the JSON.parse on the auth store with a try/catch that re-throws with the path would have made this a 10-second fix instead of a log-dive. Something like:

      Failed to parse /Users/me/.local/share/opencode/mcp-auth.json: Extra data at position 7110
      

   2. Write mcp-auth.json atomically. A trailing extra } strongly suggests a non-atomic write (write-in-place with a previous longer payload not fully overwritten, or an interrupted write merging with stale tail). Standard tmp-file + rename(2) pattern would prevent this entire failure mode.

   Let me know if you'd like a separate issue for this — the symptom (opencode mcp auth rather than runtime MCP spawning) is genuinely distinct from the original report, even though both live in the MCP subsystem.
5. Brendonovich

   closed this as completedin #26449on May 13, 2026