Remote Control: "ENOENT: Bun could not find a file" when launched from a repo on a WSL2 /mnt/c (drvfs/9p) path

Remote Control: ENOENT: Bun could not find a file when launched from a repo on a WSL2 /mnt/c (drvfs/9p) path

Summary

claude --remote-control (and claude --remote-control "Name") crashes immediately with:

ENOENT: Bun could not find a file, and the code that produces this error is missing a better error.

when the current working directory is a git repo on a Windows-mounted WSL2 path (/mnt/c/..., drvfs/9p). The exact same command works when launched from the Linux-native filesystem (~). Plain claude (without Remote Control) works fine from the /mnt/c path, and the project's stdio MCP servers spawn fine from there — so this is specific to Remote Control's startup.

Environment

• Claude Code v2.1.190 (native build, ~/.local/share/claude/versions/2.1.190)
• WSL2 (Ubuntu) on Windows; default shell /bin/bash
• Repo on /mnt/c/Users/<you>/<repo> (drvfs/9p mount)
• Plan: claude.ai OAuth (Pro/Max); no ANTHROPIC_API_KEY / long-lived token set

Reproduction

1. In WSL2, have a git repo on /mnt/c/... (with a root .mcp.json).
2. cd /mnt/c/.../<repo>
3. claude --remote-control "X" → immediate crash with the ENOENT above.
4. cd ~ && claude --remote-control "X" → connects normally (/remote-control is active …).

Ruled out

• Version (2.1.190 ≥ the 2.1.51 minimum), auth (claude.ai OAuth, no API key / no setup-token), PATH (node/npx and the MCP server binaries all resolve in the login shell), no claude alias/function/shadow, path casing (fails from both capitalized and lowercased variants of the path in a real terminal).
• stderr contains only the bare message (117 bytes) — no path, no stack trace.
• Under script(1) with a pseudo-TTY (stdin from /dev/null) it succeeds from the same /mnt/c path — so it reproduces only in a real interactive terminal, which suggests sensitivity to TTY/cwd handling at spawn time.

Likely root cause

A Bun spawn/file ENOENT on drvfs/9p shared filesystems. Related Bun issues:

• oven-sh/bun#24012 — Bun.spawn throws incorrect ENOENT when cwd doesn't exist
• oven-sh/bun#26663 — Bun misbehaves in shared/network folders
• oven-sh/bun#10743 — this exact "missing a better error" message

Suggested fixes

• Surface the actual missing path in the error message — the "missing a better error" placeholder is itself the blocker to self-diagnosis.
• realpath/canonicalize the cwd before the Remote Control spawn, or pass an explicitly resolved cwd to the spawn.
• Detect a drvfs/9p mount (/mnt/<drive>) and warn / degrade gracefully instead of crashing.

Workaround

Launch Remote Control from the Linux-native filesystem (move or clone the repo off /mnt/c).