Approval prompt persists despite repeated "don't ask again" and standing real-terminal preference

Summary

A user repeatedly selected "Yes, and don't ask again this session" for commands/file edits that require real-terminal access, but Codex continued to surface approval prompts for closely related actions. This disrupted long-running operational ML-infra work.

Environment / Surface

• Codex accessed via API/tool wrapper in a devbox session
• Installed CLI during debugging: @openai/codex version 0.141.0
• Workspace: internal devbox with workspace-write sandbox
• User had a global preference file:

/home/tiger/.codex/AGENTS.md
always run everything in real terminal shell; avoid using sandbox

The user also explicitly authorized real-terminal usage in chat multiple times.

Observed Behavior

The wrapper appears to cache approvals by exact command prefix or exact file-edit action. As a result:

• hdfs dfs -ls <specific path> approval did not generalize to other routine HDFS commands.
• bytedcli --site i18n-tt merlin ... variants could still require repeated approval depending on command shape.
• File edits outside the workspace, such as creating a global skill under ~/.codex/skills, triggered repeated "Do you want to make these changes?" prompts even after the user selected "don't ask again".
• The agent could not set a real global "use real terminal for this session/workspace" policy from chat.

Expected Behavior

After the user explicitly chooses "don't ask again this session" and has a standing preference to use real terminal, Codex should stop asking repeated mechanical approval questions for closely related routine operational commands, or provide an enforceable session-level option such as:

• "Always run commands in real terminal for this session"
• "Trust this workspace/user preference"
• "Apply don't ask again to the command family, not only exact command prefix"
• "Allow global skill/config writes after explicit user approval for this session"

Impact

For operational workflows, this causes repeated interruptions while:

• listing HDFS outputs;
• reading HDFS eval results;
• submitting Merlin jobs;
• monitoring job status;
• creating global Codex skills/preferences requested by the user.

It also makes the agent appear to ignore the user's explicit authorization.

Workaround Attempted

We created a global skill real-terminal-by-default under ~/.codex/skills instructing future agents to start HDFS/Merlin/bytedcli commands with real-shell escalation. This helps agent behavior but cannot bypass the underlying permission wrapper.

Request

Please add a session/workspace-level permission mode or improve the persistence semantics of "don't ask again" so it applies to recurring command families and user-approved global preference writes, not only exact command forms.