I built CodexGo: a policy layer for Codex permission approvals

[Fengzc]

Hi everyone,

I built CodexGo, a small CLI tool for Codex PermissionRequest hooks.

The problem: during normal development, Codex often asks for approval on repeated low-risk shell commands. I wanted a local, inspectable policy layer that can:

• allow low-risk commands like git status or test commands
• ask for sensitive commands like git push
• deny dangerous patterns like rm -rf /
• explain why a command was allowed, denied, or left to the normal Codex prompt
• suggest rules from recent approval/audit history

Example:

codexgo init --scope project
codexgo go --scope project
codexgo explain "git push"
codexgo suggest

The idea is not to bypass safety, but to make approval behavior explicit and reviewable.

Repo:
https://github.com/fengzdadi/codexgo

I’d love feedback from Codex users:

• Is policy-based approval useful for your workflow?

• Are the default allow/ask/deny boundaries reasonable?

• Would you prefer project-level policy, user-level policy, or both?

[merefield]

Nice!

I particularly like the way you can check single commands against the policy.

For me it’s always one of two cases:

• Let it rip (for off the cuff fun vibe sessions)
• Let me review every write/edit. (for more serious work)

Have you considered a PR to the main repo? I guess the hook system negates the need and provides a good plugin surface.

Btw, I built a traffic light system for my cli terminal assistant which helps to surface risk levels:

> clai: your useful command line helper!

Hey guys, I’d like to present my ongoing project I co-authored (with the help of codex-cli ). This extremely useful command line tool that provides a natural language way to describe what you want to happen at the terminal. AI has brought a lot of budding new developers into the space and it is extremely useful for CLI beginners, making the terminal much more accessible for all. It is also great for experienced users - very handy for formulating complex piped commands, or ones…

You’ve got me thinking that I could perhaps add a policy system too (but the use case is slightly different)

Out of interest did you use codex cli to build this?

[Fengzc]

Thanks for sharing the CLAI project. I had a look and the traffic light risk system is really interesting.

It feels like our projects are approaching a similar problem from slightly different angles: CLAI focuses on turning natural language into shell commands and surfacing command risk clearly, while my project is more focused on policy-based approval for Codex actions.

The new risk_appetite idea in your PR is especially close to what I’m thinking about: low-risk actions can move faster, while higher-risk ones still need explicit confirmation.

I haven’t thought much about opening a PR to the main repo yet, but after your comment I think it could be worth trying. Also, I built mine with the Codex app on macOS rather than Codex CLI. I actually find the app a bit nicer to work with than the CLI haha.