Make permission approvals more reusable and explain the saved authorization scope

Open 💬 3 comments Opened Apr 13, 2026 by qiankunli
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

App (desktop), but this likely affects other interactive Codex surfaces that use the same approval model.

What feature would you like to see?

I would like the permission / escalation approval flow to make reusable authorization much clearer, and to reduce repeated prompts for near-identical commands.

Today, the experience is hard to reason about:

  • I often want to approve a class of safe commands, not one exact shell string.
  • In practice, the remembered approval often ends up feeling tied to a very specific command shape.
  • When Codex generates long one-off shell commands such as cd <repo_root> && ..., the reusable approval scope becomes narrow and brittle.
  • The UI does not clearly explain what will actually be remembered: exact command, command prefix, working directory, argv shape, or something else.

This leads to a frustrating loop where I approve something once, then get asked again for a very similar command later.

A representative example is when Codex asks to run something like:

cd /path/to/repo/backend && PYTHONPATH=. uv run pytest tests/test_in_local/test_tracing_config.py -q

If I choose the equivalent of "yes, and don't ask again for future commands with this prefix", it is not obvious whether I just approved:

  • this exact test file
  • this exact shell string
  • uv run pytest ... in that repo
  • any pytest run in that working directory
  • or some narrower argv shape than I expect

From a user perspective, it feels too easy for the saved approval to become overly specific, which means repeated prompts for commands that are logically the same category of work.

Requested improvements:

  1. Clearly show the exact reusable authorization scope before saving it.
  • For example: "This will remember a prefix rule for [\"uv\", \"run\", \"pytest\"] in working directory ..." or whatever the real scope is.
  1. Prefer stable command shapes when presenting approval prompts.
  • If the working directory can be represented separately, avoid collapsing everything into one long cd ... && ... shell string.
  1. Let the user broaden or adjust the saved scope at approval time.
  • Example: approve only this exact command, approve this command prefix, or approve this tool family in this repo.
  1. Detect repeated near-identical approval prompts and suggest a reusable rule automatically.
  2. Document the actual mental model clearly.
  • Is approval keyed by exact argv?
  • command prefix?
  • shell wrapper shape?
  • working directory?
  • sandbox escape type?

The goal is not to weaken safety. The goal is to make the approval model understandable and reduce unnecessary repeated prompts when the user is intentionally authorizing a bounded, repeatable workflow.

Additional information

What is currently confusing is the mismatch between user intent and saved authorization behavior:

  • User intent: "stop asking me for this kind of operation".
  • Observed behavior: the saved approval can behave more like "stop asking only for this very specific command spelling".

That makes users wonder whether approval is tied to a file, a full shell string, or some hidden command-shape rule.

Even a small UX improvement here would help a lot:

  • explain what is being saved
  • normalize commands for approval when possible
  • make reusable scopes first-class in the UI instead of implicit side effects

This feels especially important for interactive use, where the value of Codex is reduced if users have to repeatedly re-approve near-duplicate commands.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

  • ##16845
  • ##16167
  • ##17449

Powered by Codex Action

Keesan12 · 2 months ago

The missing piece here is not just “fewer prompts.” It is making the approval boundary legible before the agent crosses it.

What usually breaks trust is when the user thinks they approved a class of safe work, but the system actually remembered something much narrower and keeps falling back to one-off prompts. After a while, people stop knowing whether they are approving a tool, a path, a shell shape, or just a single command spelling.

The two UX changes that would help most:

  1. show the exact reusable scope before saving it
  2. separate working directory from the command family so cd ... && ... does not turn into a fake unique permission every time

I also think there should be a plain-English reason when Codex refuses to reuse a prior approval. Something like: “same tool, different working directory” or “same repo, different elevated capability.” That would make the model feel way less arbitrary.

We ended up caring about the same problem from the other side with MartinLoop: if the operating rules around the run are fuzzy, people lose trust long before the model quality is the real blocker.

janisoteps · 18 days ago

A concrete Codex desktop use case for this request: a user keeps a small set of project-memory Markdown files in a dedicated folder outside the current workspace. The agent requests read/write access to that exact folder, and the user explicitly wants the authorization to persist so the memory can be maintained over many turns. The permission flow currently returns a turn-scoped grant, with no user-selectable session/project/persistent scope, so the same narrowly bounded folder must be approved again on later turns.

A useful UX would offer clear choices such as once, this task/session, this saved project, or always for this exact folder, with separate read/write permissions and a visible place to review or revoke saved grants. This would preserve the sandbox boundary while supporting long-lived knowledge folders and similar workflows.