CLI hard-refuses explicitly authorized infrastructure administration tasks instead of prompting for confirmation
What version of Codex CLI is running?
codex-cli 0.121.0
What subscription do you have?
ChatGPT plan with Codex access
Which model were you using?
gpt-5.4
What platform is your computer?
Linux 6.17.0-20-generic x86_64 x86_64
What terminal emulator and version are you using (if applicable)?
xterm-kitty (Kitty). No tmux/zellij.
What issue are you seeing?
In an infrastructure-admin workflow, the CLI was helpful for documentation, scripting, environment setup, and troubleshooting, but it hard-refused to perform the actual administrative action on systems under my control.
The concrete task was to enable a service on ESXi hosts that I administer. I explicitly requested the action, provided the workflow, and was willing to authorize the dangerous step. Instead of asking for a per-task confirmation or elevated authorization flow, the agent refused outright because it interpreted the task as a privileged action on real infrastructure.
From an infrastructure/operator point of view, this makes the agent much less useful: it can prepare everything around the task but cannot complete the task itself even with explicit user intent.
What steps can reproduce the bug?
- Start a Codex CLI session as an administrator/operator.
- Ask the agent to perform an administrative action on real systems under the user's control.
- Provide explicit intent/authorization, credentials, and the exact workflow.
- Observe that the agent may help with prep work (docs/scripts/env fixes), but refuses to execute the real administrative action itself.
Uploaded thread: 019d96ca-c00c-77f0-b882-8c6a0b8e4b45
What is the expected behavior?
For explicitly authorized admin operations, the CLI should support a gated execution path rather than an unconditional refusal. A more useful behavior would be:
- detect that the task is sensitive
- require explicit user confirmation per action or per batch
- execute with auditability/logging
- optionally provide post-action validation and rollback guidance
In other words: asking for strong confirmation is reasonable; outright refusal is not useful for legitimate infrastructure administration workflows.
Additional information
I am not reporting poor technical quality from the agent. The technical help was good. The issue is the product behavior/policy boundary: the CLI can assist around the task but not complete the authorized task itself, which is a major limitation for infrastructure/operations use cases.
I also sanitized the uploaded thread before filing this issue so it should not contain the real secret, hostnames, IPs, or direct access URLs.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗