CLI hard-refuses explicitly authorized infrastructure administration tasks instead of prompting for confirmation

Resolved 💬 2 comments Opened Apr 16, 2026 by sebastian73m Closed Apr 16, 2026

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?

  1. Start a Codex CLI session as an administrator/operator.
  2. Ask the agent to perform an administrative action on real systems under the user's control.
  3. Provide explicit intent/authorization, credentials, and the exact workflow.
  4. 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.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗