Repository navigation
Validate workspace roots at task creation/resume; surface "working directory not found" instead of downstream spawn ENOENT #39780
Description
Summary
A task rooted at a path that doesn't exist locally is created without warning. Every subsequent child-process spawn fails with ENOENT, which silently prevents the node_repl MCP server from starting — so the Computer Use plugin injects its SKILL.md but registers zero callable tools. The user sees "Computer Use isn't working" with no indication the working directory is the cause.
Mechanism
nonexistent task cwd
-> child-process spawn returns ENOENT
-> node_repl MCP server cannot start for that task
-> Computer Use exposes SKILL.md but no callable tools
Repro
Register a local project whose root is another macOS user's home. Create a task in it. Invoke @Computer.
Observed:
CreateProcess: Rejected("Failed to create unified exec process: No such file or directory (os error 2)")for both/bin/bashand/bin/zshFailed to watch workspace root for git init cwd=... errorCode=ENOENT- Tool catalog logs
omitting MCP server without an exact ready client server_name=node_repl
Control: an identical task under a valid local root passes all four checks — pwd, SKILL.md read, all three mcp__node_repl__js* tools registered, and a live sky.get_app_state({app:"Finder"}) capture. No reinstall, no permission change.
Why the error is misleading
No such file or directory reads as a missing binary. Both shells exist. The missing entity is the cwd, several layers removed from where the error surfaces.
Asks
- Validate the workspace root at task creation and resume; refuse or warn with
working directory not found: <path>. - When an MCP server fails to start, surface that in the task rather than silently omitting it from the tool catalog.
- Offer rebinding for tasks whose root is invalid, or state plainly that it isn't supported —
cwdis written into the rollout at creation and never re-read, so affected tasks are permanently unusable for execution while retaining full history.
Activity
Collaboration95 commentedon Aug 25, 2026
Additional macOS reproduction: a stale local-project path also prevents creating new chats after a folder rename.
Environment:
Reproduction:
Observed:
Expected:
Workaround confirming the cause:
Related reports: #11022, #20934, and #40303.
it-yusha commentedon Aug 26, 2026
A verified single-thread recovery may also help users affected by a stale or nonexistent task
cwd.In my case, the saved Desktop project root was correct, but one existing thread retained an old, nonexistent
cwd. App and macOS restarts did not fix it. After backing up state and fully quitting Desktop to release the active writer, resuming that same thread once with the correct-Cpath and a read-only verification prompt repaired the persistedcwd. The original thread ID and history were preserved, and the corrected path remained stable after reopening Desktop and running a subsequent normal turn.Full environment, command, verification points, and cautions are documented here:
#24855 (comment)
This is only a version-specific, single-thread recovery example. It still consumes one model turn and does not replace the workspace validation and first-party relink flow requested in this issue.
vanjaoljaca commentedon Oct 2, 2026
Additional reproduction on macOS, ChatGPT desktop 26.928.20755 (build 12246), observed 2026-10-02.
An existing desktop chat has a saved working directory that no longer exists. The in-app browser remains visible and usable by the human, and ambient tab URL context reaches the assistant. The assistant can call codex_app tools, including open_in_codex, but no cua_repl, node_repl, or browser interaction tools are exposed. Restarting the app did not restore them.
Read-only evidence:
MCP startup failed: No such file or directory (os error 2).--versionraises errno 2 when cwd is the missing task directory, and succeeds (v24.21.0, exit 0) when cwd is an existing directory.This strongly matches the invalid-cwd failure described here. We have not yet verified a repaired browser-tool handshake; the exact MCP launch cwd has not been independently traced. No signed-app patch, live database edit, auth copying, or security bypass was attempted.
Please surface the missing workspace path as the actionable error and offer a supported way to rebind an existing chat to its moved directory and restart its failed MCP clients. Currently a working signed-in browser misleadingly appears disconnected, leading to repeated logins and restarts that cannot fix a missing cwd.
Private paths, account identifiers, recipient emails, and raw logs are omitted.