›_ Codex Issues
Codex Issues / #9932

~/.codex/ treated as project config when running from home directory

Resolved 💬 12 comments Opened Jan 26, 2026 by 0xble Closed Feb 2, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.91.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.2-codex

What platform is your computer?

macOS (Darwin 25.2.0), zsh, installed via Homebrew

What issue are you seeing?

When running codex from the home directory (~), the global config folder ~/.codex/ is treated as both a user config (trusted) and a project config (untrusted), causing this warning:

⚠ The following config folders are disabled:
1. /Users/username/.codex
   Add /Users/username as a trusted project in /Users/username/.codex/config.toml.

The ~/.codex/ folder is the canonical user config location and shouldn't require explicit trust as a "project."

Root cause

In codex-rs/core/src/config_loader/mod.rs, the config loading works as follows:

  1. User config is loaded from $CODEX_HOME/config.toml (lines 164-174) - always trusted
  2. Project configs are found by load_project_layers() walking from cwd up to project root, looking for .codex/ folders (lines 658-748)

When cwd is the home directory and no .git marker is found, find_project_root() returns cwd itself. Then load_project_layers() finds ~/.codex/ and treats it as a project config requiring trust.

The issue is that load_project_layers() doesn't check if the discovered .codex/ folder is the same as $CODEX_HOME.

Steps to reproduce

  1. cd ~
  2. Ensure ~ has no .git directory (or ancestors with .git)
  3. Run codex
  4. See the warning about disabled config folders

Expected behavior

~/.codex/ should not require trust when it's the user's global config directory. The load_project_layers() function should skip directories where dot_codex == codex_home.

Suggested fix

In load_project_layers(), add a check to skip when the discovered .codex/ folder matches $CODEX_HOME:

let dot_codex = dir.join(".codex");
let dot_codex_abs = AbsolutePathBuf::from_absolute_path(&dot_codex)?;

// Skip if this is the user's global config directory
if dot_codex_abs.as_path() == codex_home {
    continue;
}

Workaround

Add the home directory as a trusted project in ~/.codex/config.toml:

[projects."/Users/username"]
trust_level = "trusted"

View original on GitHub ↗

12 Comments

kingtistel · 5 months ago

Me too,
❗️ except when applying the W/A, then when running next from home directory I get Sandbox = "workspace-write" instead of "read-only" 👇🏼

<img width="593" height="573" alt="Image" src="https://github.com/user-attachments/assets/055349a3-0f9c-480d-856a-b856d096aff6" />

kingtistel · 5 months ago

Actually it might be worse:
On first invocation from home directory we are asked to choose (default being read-only):

> You are running Codex in /Users/ophers

  Since this folder is not version controlled, we recommend requiring approval of all edits and commands.

  1. Allow Codex to work in this folder without asking for approval
› 2. Require approval of edits and commands

  Press enter to continue

This writes the below to ~/.codex/config.toml:

[projects."/Users/username"]
trust_level = "untrusted"

and subsequent invocations from home directory will still set Sandbox to "workspace-write" 👇🏼

<img width="1164" height="643" alt="Image" src="https://github.com/user-attachments/assets/223ad9d8-dbda-4ebc-b031-3566293c38d8" />

bahmanm · 5 months ago

Happens in Git worktress too; even with the workaround suggested above.

Project config.toml files are disabled in the following folders. Settings in those files are ignored, but skills and exec policies still load.
      1. /PATH-TO-HOME-DIR/FOO-WORKTREE/.codex
         To load config.toml, add /PATH-TO-HOME-DIR/FOO-REPO as a trusted project in /PATH-TO-HOME-DIR/FOO-WORKTREE/.codex/config.toml.

In particular, the tweak which the application recommends is quite twisted IMO.

tlex · 5 months ago

The risk associated with trust_level = "trusted" for the whole home directory is quite bad.

I only see a rollback as a solution to this.

Rohlik · 5 months ago

Getting that message also in the Codex extension in VS Code whenever I open chat.

joshleelab · 5 months ago

I get this error in vscode as well, and it seems that project .codex/config.toml aren't overriding

sillycube · 5 months ago

The same here. I use the codex extension in cursor (mac os). I try to add trusted_projects = ["home/user"] but it's still the same. The warning keeps appearing when I open the ide -> extension

NormanMises · 5 months ago
I get this error in vscode as well, and it seems that project .codex/config.toml aren't overriding

same, it also shows when I open other dir not under home.

kingtistel · 5 months ago

Hi @daniel-oai ,
I just updated to v0.93.0 and while it fixed the warning issue, it missed one issue I mentioned earlier
https://github.com/openai/codex/issues/9932#issuecomment-3811966217

Should I report it as a new issue?
Thanks.

etraut-openai contributor · 5 months ago

@kingtistel, yes, please open another issue so it doesn't get lost. Thanks!

kingtistel · 5 months ago

@etraut-openai

@kingtistel, yes, please open another issue so it doesn't get lost. Thanks!

https://github.com/openai/codex/issues/10395

daniel-oai contributor · 5 months ago

Glad to hear we fixed at least part of it. Ill try and get the next fix out soon as well

Fixed the initial error here
Skip loading codex home as project layer #10207

Will update the next one