v0.131 regression: codex starts in the wrong folder

[howardjohn]

What version of Codex CLI is running?

v0.131.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.5

What platform is your computer?

Linux

What terminal emulator and version are you using (if applicable)?

No response

Codex doctor report

What issue are you seeing?

I have a folder structure like

repo/
  some-folder/
  .worktrees/some-branch1/some-folder
  .worktrees/some-branch2/some-folder

Before v0.131: I open codex in repo/.worktrees/some-branch1 folder. It runs in repo/.worktrees/some-branch1
After: v0.131: I open codex in repo/.worktrees/some-branch1 folder. It runs in repo/ silently ignoring my current directory. I run commands against the wrong branch and chaos ensues.

What steps can reproduce the bug?

See above

What is the expected behavior?

As a user I expect codex to run in the folder I told it to run from

Additional information

No response

[zhang-liz]

Walking the v0.130 → v0.131 cwd flow to help triage this.

The cwd path is intact on paper

The default-cwd plumbing (no --cd passed) is:

1. CLI default for --cd is None — shared_options.rs:61.
2. ConfigOverrides { cwd: shared.cwd, ... } — cli/src/main.rs:1699.
3. ConfigBuilder resolves cwd_override.unwrap_or(env::current_dir()) — config/mod.rs:1094-1099, final resolved_cwd at config/mod.rs:2536-2553 (normalize_for_native_workdir is a no-op on Linux per path-utils/src/lib.rs:139-145).
4. config.cwd = resolved_cwd — config/mod.rs:3360.
5. session_configuration.cwd = config.cwd.clone() — session/mod.rs:624.
6. SessionConfiguredEvent.cwd = session_configuration.cwd.clone() — session/session.rs:996.
7. TUI: self.current_cwd = Some(session.cwd.to_path_buf()); self.config.cwd = session.cwd.clone(); — chatwidget/session_flow.rs:34-35.

Nothing in that chain reassigns cwd to the main-repo root, so on a clean fresh-session invocation the reported symptom shouldn't be possible by env::current_dir() alone.

Two likely culprits introduced in the v0.130→v0.131 window

a. Worktree-aware project-layer loader (#21969, 934a40c7d9). Adds find_git_checkout_root (loader/mod.rs:1094-1109) and routes project-hook config through the main-repo .codex/. The PR is hook-scoped by design, but it changes which .codex/ folder backs the project layer for linked worktrees — if any later code derives an "effective directory" from the project-layer source path instead of config.cwd, that's where the worktree path would be lost.

b. Workspace-roots-in-profiles series (#22610, #22611, #22612, #22624). v0.131 surfaces effective_workspace_roots() in several user-visible places (status line, exec summaries). If the active permission profile resolves :workspace_roots symbolically and the resulting first root is the canonicalized main-repo root (via resolve_root_git_project_for_trust, which deliberately walks worktrees back to the main repo), the user could perceive Codex as "running in repo/" even when config.cwd itself is correct — depending on which surface they read it from.

Note resolve_root_git_project_for_trust was designed to return the main repo root from inside a worktree — that's correct for trust lookups, but anywhere it's used to derive an operating directory would produce exactly this symptom.

Questions for @howardjohn that would localize this fast

1. Does codex doctor (from inside repo/.worktrees/some-branch1) report cwd: as the worktree path or the main-repo path?
2. Where do you observe Codex "running in repo/" — the status-line/header text, the agent's actual shell-tool pwd, or files the agent reads/writes? Each surface goes through a different code path.
3. Does setting --cd $PWD on the v0.131 invocation make the symptom go away? If yes → the env::current_dir() → resolved_cwd path is fine and the regression is downstream; if no → the regression sits in something that overrides cwd after ConfigBuilder.
4. Does the worktree contain a .codex/ folder, and is there a .codex/ at repo/? Different combinations exercise different branches of load_project_layers.

Offer

Happy to drive a bisect across rust-v0.130.0..rust-v0.131.0 against a reproduction fixture and submit a PR if a maintainer would like to invite one.

I have read the CLA Document and I hereby sign the CLA

[ben-vargas]

I’ve run into similar tonight, running 0.131.0 and launching codex from ~/projects/some-project is loading codex cli with cwd set to ~ shown in the status line and evidenced by gpt-5.5 having no idea what I’m talking about and acting from the root dir of my account.

I’m suspect of some kind of conflict between Codex App running on same MBP maybe starting an app-server instance or something that is getting inherited. Haven’t dug deeper yet, but definitely nothing weird in my toml and it’s definitely since upgrading to 0.131.0

Edit: Reverting the codex cli binary back to 0.130.0 solves the problem, this only changes the version i run with the codex terminal command, bundled binary in the Codex App on my mac remains 0.131.0-alpha.9

[sapjax]

Same here. can't believe such a serious problem appeared in the prod version. My session history is in chaos. Didn't you test it?

[milesian01]

Same issue here, in really bad shape. Using --cd $PWD is the only way to get it started where I expect, but when I use the "implement plan in new session" coming out of plan mode, the new session just lands me in random cwd's then chaos ensues.

Interestingly this cwd issue is related to another post-0.131 bug: my skill picker suddenly shows "no available skills" despite the skills themselves being present in the prompt as expected. Somehow using --cd $PWD fixed this skill picker issue. Hopefully this helps your investigation.

[ben-vargas]

I restarted my macbook pro and then re-upgraded again to 0.131.0 (I had rolled back to 0.130.0) and the directory issue has gone away. I suspect an older versioned codex app-server or codex remote-control process was being detected and used when launching the updated 0.131.0 version... pure speculation, but curious if it fixes it for anyone else? Or perhaps closing Codex App and or killing other codex processes to zero running and then try launching 0.131.0 CLI?

[kcosr]

Possibly related, I have a session that started in dir1 that I've been using from dir2 with resume. When I resume now it doesn't give me the picker to run in the alternate dir2 (cwd), it uses dir1. Then I get Failed to read thread goal: thread/goal/get failed in TUI when trying to start a goal. v0.131.0 CLI on Linux.

[winoros]

All my CLI sessions' cwd becomes ~/. It's horrible.

It seems that the cwd will be wrong once there's a live app server. And the issue exists whether the app server is started by App or by hand.

[winoros]

Another issue I realize is: the root dir is not trusted, but the cli can still choose it as working dir and start the session.