›_ Codex Issues
Codex Issues / #39780

Validate workspace roots at task creation/resume; surface "working directory not found" instead of downstream spawn ENOENT

Open 💬 2 comments Opened Aug 20, 2026 by intellicoins1

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/bash and /bin/zsh
  • Failed 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

  1. Validate the workspace root at task creation and resume; refuse or warn with working directory not found: <path>.
  2. When an MCP server fails to start, surface that in the task rather than silently omitting it from the tool catalog.
  3. Offer rebinding for tasks whose root is invalid, or state plainly that it isn't supported — cwd is written into the rollout at creation and never re-read, so affected tasks are permanently unusable for execution while retaining full history.

Related: #29438, #26026

View original on GitHub ↗

2 Comments

Collaboration95 · 3 days ago

Additional macOS reproduction: a stale local-project path also prevents creating new chats after a folder rename.

Environment:

  • Codex Desktop on macOS 26.5.2
  • Bundled Codex CLI 0.149.0

Reproduction:

  1. Register a local project while its repository is at path A.
  2. Rename/move the repository to path B.
  3. Confirm that path B exists and is a valid Git repository.
  4. Open the original saved project entry in Codex.
  5. Try to create a new chat.

Observed:

  • The saved project entry continued to reference path A.
  • Path A no longer existed, so Codex reported that the project folder was moved or deleted and would not create a new chat in that project.
  • Existing thread metadata/catalog rows also retained path A.
  • A second project entry created from path B was detected as a Git repository, but it did not preserve the original project’s chat association.
  • The failure is at the project-root association layer, before any repository operation.

Expected:

  • Detect that the saved project root is missing and offer “Locate/Rebind project folder”.
  • Update the saved project root from A to B while preserving the existing project ID, chats, history, and thread associations.
  • Reconcile saved thread working directories and writable roots on resume.
  • Surface the missing working directory explicitly at chat creation rather than requiring a new project or manual internal-state changes.

Workaround confirming the cause:

  • A symlink from path A to path B immediately made the original project entry detect as a Git repository and become usable again. This is only a workaround; Codex should migrate the stored path safely.

Related reports: #11022, #20934, and #40303.

it-yusha · 1 day ago

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 -C path and a read-only verification prompt repaired the persisted cwd. 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:
https://github.com/openai/codex/issues/24855#issuecomment-5428366748

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.