Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

app-server rejects every turn with "invalid cwd" once the daemon's own working directory is deleted, even when the request cwd is absolute

Open Beginner friendly
  • Is something wrong?
#51,152 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
backend-api-design

Research direction

Start by reading codex-rs/utils/absolute-path/src/lib.rs around relative_to_current_dir, then check its caller in codex-rs/app-server/src/request_processors.rs and the turn and resume call sites named in the issue. Done means an absolute request cwd resolves even when the daemon's own working directory has been deleted, while relative paths still resolve against the current directory.

Written by the indexing model from the issue text.

Description

app-server bug CLI

What happens

The shared app-server daemon starts with the working directory of the first codex invocation that spawns it. If that directory is later deleted (a removed git worktree, for example), every new turn/start on that daemon fails:

turn/start failed: invalid cwd: No such file or directory (os error 2) (code -32600)

This happens even though the turn's own cwd is an absolute path to a directory that exists. Every TUI attached to the daemon is affected until the daemon restarts. codex resume <thread> --no-daemon works around it for one session.

Why

resolve_request_cwd (codex-rs/app-server/src/request_processors.rs:629, rust-v0.160.0) resolves the request cwd with AbsolutePathBuf::relative_to_current_dir:

fn resolve_request_cwd(cwd: Option<PathBuf>) -> Result<Option<AbsolutePathBuf>, JSONRPCErrorError> {
    cwd.map(|cwd| {
        AbsolutePathBuf::relative_to_current_dir(path_utils::normalize_for_native_workdir(cwd))
            .map_err(|err| invalid_request(format!("invalid cwd: {err}")))
    })
    .transpose()
}

relative_to_current_dir (codex-rs/utils/absolute-path/src/lib.rs:87) calls std::env::current_dir()? unconditionally, before it looks at whether path is already absolute:

pub fn relative_to_current_dir<P: AsRef<Path>>(path: P) -> std::io::Result<Self> {
    Ok(Self::resolve_path_against_base(
        path,
        std::env::current_dir()?,
    ))
}

On Linux, getcwd fails with ENOENT when the process's cwd has been unlinked. So an absolute request path is rejected because of the daemon's own cwd, which the path does not depend on. The same call is used for turn/start (turn_processor.rs:621, :928) and thread resume (thread_processor.rs:3877).

Reproduce

  1. With no daemon running (codex app-server daemon stop), run mkdir /tmp/x && cd /tmp/x && codex. This starts the daemon with cwd /tmp/x. Exit the TUI.
  2. rm -rf /tmp/x
  3. cd ~/some/repo && codex, then send any prompt. The turn fails with invalid cwd.

Expected

An absolute request cwd resolves without consulting the process cwd. Only a relative request cwd needs current_dir(), and its error could say that the daemon's working directory no longer exists.

Possible fix: in relative_to_current_dir, return from_absolute_path(path) when path.is_absolute(), and call current_dir() only for relative input.

Related

The managed daemon and its updater both inherit the spawning terminal's cwd (codex app-server daemon start, and Daemon::stop leaves daemon-updater.pid running). So after stop + start, the next update recreates the daemon in the deleted directory again; only daemon bootstrap replaces both processes. Starting the managed daemon from a stable directory (for example $CODEX_HOME) regardless of the caller's cwd would remove the whole class.

Environment: codex-cli 0.160.0 (npm, linux-x64 musl), Ubuntu, managed app-server daemon (codex app-server --listen unix:// --managed-daemon).

Related report: #41559 (a session whose own cwd was removed). This issue is a different trigger: the request cwd exists and is absolute, and only the daemon process's cwd is gone.

Dominant language
Rust
Stars
127k
Forks
19.9k
Avg merge
1m
Merged PRs (30d)
994

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/codex

All issues in openai/codex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.