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 ?