Allow trust_level = "trusted" for any projects

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #14345
• #14547

Powered by Codex Action

that probably should work by glob(/opt/projects/ or / is user feels risky), not just allow_anything = true

I would like to see this too, although for a different reason: the absolute paths to trusted projects are currently added to ~/.codex/config.toml, which means if this file is committed to a public dotfiles repo (a reasonable thing someone might want to do) it leaks the project directory names (which can obviously be undesirable).

I agree with keramblock that a glob/wildcard approach would probably be the best solution here. E.g.:

[projects."/home/user/code/*"]
trust_level = "trusted"

Am I correct in understanding that the trust level is specifically for enabling/disabling project-specific .codex configs to be merged with user-global ~/.codex configs when working in that directory? In that case, since I don't need or want project-specific configs anyway, I'd want to be able to do the opposite of what's requested in this issue, i.e. to mark every directory as _untrusted_ instead of trusted. (This is assuming that trust_level is separate from approval_policy and sandbox_mode, which I do want set permissively.)

In case anyone finds it useful, as a stopgap solution I'm using a wrapper script like this to achieve the same effect until OpenAI implements this sort of glob config:

import json
import os
import sys
from pathlib import Path


def main() -> None:
    project = json.dumps(str(Path.cwd()))
    config = f'projects={{{project}={{trust_level="trusted"}}}}'
    os.execvp("codex", ["codex", "-c", config, *sys.argv[1:]])


if __name__ == "__main__":
    main()

No updates on this? This is a severe regression that has not been fixed for over3 weeks.

@milanglacier, this isn't a regression. It's a feature request. We prioritize feature requests based on community inputs (upvotes). This one has received some upvotes, but there are many features ahead of it in the queue.

@milanglacier, this isn't a regression. It's a feature request. We prioritize feature requests based on community inputs (upvotes). This one has received some upvotes, but there are many features ahead of it in the queue.

This is a regression according to #14345.
While the scope of this issue and #14345 is different, and developers can solve the two issues in different ways. But essentially they are pointing to the same aspect of bad user experience that codex users have been facing since the release of v0.113.

I would like to see this too, although for a different reason: the absolute paths to trusted projects are currently added to ~/.codex/config.toml, which means if this file is committed to a public dotfiles repo (a reasonable thing someone might want to do) it leaks the project directory names (which can obviously be undesirable). I agree with keramblock that a glob/wildcard approach would probably be the best solution here. E.g.: [projects."/home/user/code/*"] trust_level = "trusted"

This is exactly why I happened to find this issue.

Any updates people ?

We've decided to make all directories trusted by default unless you are using :read-only permissions. This makes the CLI (TUI) consistent with the desktop app's behavior. This will be included in the next release.

Every tool with such power (or way less) asks whether you trust the code or folder you’re about to work with. Visual Studio Code - an industry leader in "working with stuff that is in a folder" - is a good example.

Defaulting to trusting every folder in which someone runs codex will inevitably lead to people running it from ~/ or, worse, from somewhere containing sensitive files they never intended Codex to access.

Is that really the security tradeoff we want to make, just to save users two keystrokes?

A trust prompt is a tiny amount of friction at exactly the point where a little friction is valuable.

@smileBeda, agree. After further internal discussion, we've decided not to move forward with this change. Reopening this issue.

Phew.

---

A companion on Discord mentioned that allowing wildcards would be a solution they'd prefer, and that would also be safe in the sense that it doesn't amount to a blanket allowance.

In short, they propose allowing something like:

[allowed_dirs]
/path/to/dir/*

This would trust all directories inside /path/to/dir/, but not /path/to/dir/ itself, its parent directories, or its siblings.
That would satisfy both the "we cannot bear to tap once to allow trust" faction and the "we cannot bear to just let Codex spin its wheels wherever it wants" faction.

PS:

• https://github.com/openai/codex/issues/14599#issuecomment-4070239742
• https://github.com/openai/codex/issues/14599#issuecomment-4066898390

suggest similar approaches preserving safety and giving flexibility.

If YOLO mode is _actually_ asking for those confirmations (did not confirm, I am not using YOLO), then I would consider that indeed a BUG - but for YOLO mode only 😅

Every tool with such power (or way less) asks whether you trust the code or folder you’re about to work with. Visual Studio Code - an industry leader in "working with stuff that is in a folder" - is a good example.

Not everyone agrees VS Code is a good example to copy here. For instance, this security researcher criticized the VS Code popup by saying that it "is just noise and desensitizes the user to the real underlying security threat": https://news.ycombinator.com/item?id=46725548

If YOLO mode is _actually_ asking for those confirmations (did not confirm, I am not using YOLO), then I would consider that indeed a BUG - but for YOLO mode only 😅

That is in fact exactly the behavior, which is why people complained about this in the first place:

• https://github.com/openai/codex/issues/14345

That is in fact exactly the behavior, which is why people complained about this in the first place:

On _that ticket_, this one here is about a global blanket trust. And that is for described reasons a bad idea. It is obviously enough not a good idea to just let codex run in any dir without first approving it, this is not even about "trust this directory content", but "trust codex to read this directory" to start with.
Yes, it technically still could somehow escape, but we do not need to make it easier, right?

The proposed wildcards (or even the more hammer-like OP original proposal) would solve the gripe people have expressed _here_, which is not about YOLO being not full YOLO.

All I'm pointing out is that the thing you said you would agree is a bug is indeed the case.

Visual Studio Code - an industry leader in "working with stuff that is in a folder" - is a good example.

Then at least we should use that example fully, VS Code has "security.workspace.trust.enabled" setting which allows users to fully disable the annoyance.
I think the ones who don't like this feature are fine with having to manually turn it off once and for all in their settings, I'm fine with that.

@smileBeda, agree. After further internal discussion, we've decided not to move forward with this change. Reopening this issue.

This is also related to: https://github.com/openai/codex/issues/14601

If manual confirmation is expected, can we move the [project.xxxx.trusted] entries to state.toml rather than spamming config.toml to prevent config pollution. People relies on dotfiles syncs (nix, chezmoi, GNU Stow, or just home-mode symlink shell-script) cannot sync codex's config.toml reliable because it is polluted with those states rather than actual configuration.

This is also claude code's behavior. User set configuration is stored under ~/.claude/settings.json so that is dotfiles manageable, and the state (like trusted projects) are stored under ~/.claude.json.