Codex desktop repeatedly blocks authorized localhost security validation and cross-repository report writes

What version of the Codex App are you using (From “About Codex” dialog)?

26.715.31925

What subscription do you have?

Plus Plan

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

Codex repeatedly interrupted an explicitly authorized defensive security review of user-owned source code and disposable local Podman containers.

The restrictions were broad enough that the workflow could identify potential vulnerabilities but could not reliably finish verification or write a remediation report to the repository being assessed.

I am not requesting unrestricted execution. I am requesting durable, narrowly scoped authorization for defensive work against explicitly identified local resources.

Environment

• Windows
• Codex desktop app
• Managed/workspace-write sandbox
• Primary workspace in one local repository
• A second, user-owned local repository being assessed
• Local Podman containers bound only to localhost
• No third-party systems or production targets
• No destructive production operations
• Explicit user authorization was given for read-only assessment and local Podman validation

Repository names, paths, credentials, and vulnerability details are intentionally omitted from this public issue.

What steps can reproduce the bug?

Workflow

1. Open repository A as the active Codex workspace.
2. Ask Codex to assess repository B, which is another user-owned local repository.
3. Explicitly authorize read-only source inspection and local Podman validation.
4. Run a temporary container on localhost to validate an MCP/HTTP service.
5. Ask Codex to document sanitized, patch-oriented findings in repository B.
6. Continue static analysis without external network access or third-party targets.

Actual behavior

• Narrowly scoped defensive operations repeatedly triggered blocked requests or approval failures.
• Authorization did not persist for the clearly identified repository and local test environment.
• Similar actions had inconsistent outcomes, making the workflow unpredictable.
• It was not clear which exact operation or policy rule caused each block.
• Attempts to avoid active tests and continue with read-only/static analysis still resulted in interruption from the user's perspective.
• Writing a single Markdown report to the explicitly authorized second repository required another problematic escalation because it was outside the initially writable workspace.
• The workflow ultimately had to be stopped without creating the requested remediation report.

What is the expected behavior?

Expected behavior

After explicit confirmation, Codex should support a task-scoped authorization such as:

• Read repository B.
• Write only a named Markdown report in repository B.
• Build and run disposable Podman containers from repository B.
• Bind test services only to localhost.
• Remove only containers created by the current task.
• Deny external targets, broad filesystem writes, credential disclosure, and unrelated destructive actions.

That authorization should remain effective for the task unless the requested scope changes.

When an operation is blocked, the UI should identify:

• The exact requested operation
• The affected path, container, or network destination
• Whether the block came from filesystem sandboxing, network policy, command review, or another safety classifier
• Why an earlier approval did not cover it
• The smallest additional permission needed to continue

Security impact

Overly broad restrictions can make software less secure.

In this case, Codex could identify security-sensitive behavior but could not complete the normal defensive lifecycle:

1. Reproduce safely
2. Retain diagnostic evidence
3. Document the affected component
4. Define acceptance tests
5. Patch
6. Verify the remediation

Stopping between discovery and remediation leaves known risks unresolved.

Requested improvements

1. Add durable repository-scoped authorization for the current task.
2. Treat localhost and disposable-container security testing separately from testing external systems.
3. Distinguish read-only inspection, bounded writes, local execution, external access, and destructive actions as separate risk levels.
4. Allow approval rules for exact directories, command families, bind addresses, and container-name prefixes.
5. Show the precise policy source and reason for every blocked request.
6. Provide a constrained defensive-testing mode instead of rejecting the entire workflow.
7. Permit a specifically named report file to be written to another explicitly approved local repository.
8. Preserve approvals across repeated equivalent operations within the same task.
9. Provide a task-level audit log of approved, denied, and executed operations.

Safety boundaries that should remain

This request is not asking Codex to bypass safety controls. The following restrictions would still be appropriate:

• No access to third-party targets without separate authorization
• No credential disclosure
• No broad or recursive deletion
• No unrestricted writes outside approved repositories
• No public exploit publication
• No expansion from localhost testing to external systems
• No reuse of an approval for materially different commands or targets

Additional information

Additional information

I can provide private task identifiers, timestamps, screenshots, and exact blocked messages to OpenAI Support. They are omitted here because this is a public issue.