Support recursive trusted project roots

Open 💬 4 comments Opened Apr 24, 2026 by mayurj747

What variant of Codex are you using?

CLI

What feature would you like to see?

Codex currently appears to require exact per-repo trust entries like:

[projects."/Users/me/repos/some-repo"]
trust_level = "trusted"

For users who keep many trusted repositories under a known parent directory, it would be useful to support an explicit trusted umbrella/root, for example:

[projects."/Users/me/repos"]
trust_level = "trusted"
recursive = true

or an equivalent dedicated setting such as:

trusted_roots = ["/Users/me/repos"]

This would let repositories under /Users/me/repos/* inherit trusted status without cluttering config.toml with one entry per repo. Exact child entries should still be able to override the inherited trust, e.g. marking a sensitive subdirectory as untrusted.

Additional information

Related pain points have come up around exact-path trust, wildcard/global trust not working, and config.toml accumulating many auto-added trust entries. This request is narrower than trusting every directory globally: it asks for an explicit recursive trust boundary chosen by the user.

View original on GitHub ↗

4 Comments

chenrui333 · 3 months ago

I would also use this. My repos are often grouped under a trusted parent directory with many child repos/worktrees, so exact per-repo trust entries make config.toml grow quickly.

The VS Code-style model of trusting a parent folder recursively feels like the right user expectation here, especially if explicit child entries can still override inherited trust for sensitive paths.

TonyGravagno · 3 months ago

👍 for recursive = true on a group. In my example I would use it on the repo subfolder, maybe the codex folder.

Without it, the redundancy feels sloppy, especially non-alphabetized:

[projects."/opt/codex"]
trust_level = "trusted"

[projects."/opt/codex/repo/bbb"]
trust_level = "trusted"

[projects."/opt/codex/repo/aaa"]
trust_level = "trusted"

xuanswe · 3 months ago

I think it's better to use glob matching (e. /opt/codex/repo/*) for flexibility.

alaestor · 22 days ago

dumb workaround is to use a wrapper script that checks pwd against allowed directories and then sets it as trusted for the session using -c like this (tho personally, I just live dangerously by trusting whatever directory I run my wrapper from)

Pattern-based rules for project trust and command allowlisting have been on many people's wishlist for way too long...

I can see the "but safety" arguments, but they're pretty weak imo; anyone who wants those guarantees can stick to existing systems while the rest of us could opt-in to pattern matchers.