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
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 ↗

2 Comments

github-actions[bot] contributor · 4 months ago

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

  • #17660
  • #18005
  • #17623

Powered by Codex Action

etraut-openai contributor · 4 months ago

Thanks for the bug report. We'll share the feedback with the team responsible for training our codex models. We're tracking this feedback and similar reports so we can improve future models. And thanks for using the /feedback command. That additional information is useful.