Approval prompt (p) "don't ask again" persists across sessions and workspaces with program-name-only scope

What version of Codex CLI is running?

codex-cli 0.130.0

What subscription do you have?

Pro (Enterprise)

Which model were you using?

gpt-5.5

What platform is your computer?

Darwin 25.4.0 arm64

What terminal emulator and version are you using (if applicable)?

_No response_

What issue are you seeing?

## Summary

The (p) "don't ask again for commands that start with X" option in approval prompts creates an unexpectedly broad, durable allow-rule. For program-name prompts like curl, approving with (p) once permanently allows any future invocation of that program, across
sessions, across workspaces, with no expiry. The prompt wording does not convey this scope.

What steps can reproduce the bug?

## Steps to reproduce

1. Start codex in a fresh project with sandbox restrictions that gate network access (e.g. workspace-write default).
2. Prompt the agent to run a network command:

``
run: curl -s https://httpbin.org/ip
``

1. Codex displays the approval prompt:

```
Would you like to run the following command?
$ curl -s https://httpbin.org/ip

1. Yes, proceed (y)
2. Yes, and don't ask again for commands that start with curl (p)
3. No, and tell Codex what to do differently (esc)

```

1. Select (p).
2. In the same session, prompt a different curl command:

``
run: curl ipinfo.io
``
→ runs silently with no prompt (different URL, no flags — but still matches "starts with curl").

1. Quit codex. Restart codex in a different workspace directory.
2. Prompt: run: curl https://example.com

→ still runs silently with no prompt.

Options set in requirements.toml

 Sandbox: workspace-write and sandbox_workspace_write].network_access = false

What is the expected behavior?

## Expected behaviour

A few reasonable expectations any of which would be safer than current behavior:

• Persistence scoped to the session only (cleared on codex restart), OR
• Persistence scoped to the specific command + args (matching the prompt's literal command, not just program name), OR
• Persistence scoped to the workspace the approval was granted in, OR
• An explicit indication in the prompt that the rule is durable and cross-workspace, with an option to set duration.

The prompt wording — "for commands that start with curl" — reads like an in-session convenience. The actual scope is "forever, anywhere on this machine, any args."

## Actual behaviour

A single approval grants permanent, cross-session, cross-workspace allow on the program name. The allow appears to be persisted (likely in ~/.codex/config.toml or related state) and is never re-prompted.

This is meaningful as a security concern because:

• Approval-fatigued users habitually pick (p) to silence prompts.
• The intuitive read of "starts with curl" suggests narrow scope; the actual scope is much wider.

Additional information

_No response_