openai / openai/codex

Clarify apply_patch guarantees and supported exclusive file creation in Codex CLI

Open
#43,467 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

CLI documentation tool-calls
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

What is the type of issue?

No response

What is the issue?

Environment: Codex CLI 0.149.0 on WSL2/Linux, with an ext4 project filesystem.

I am requesting documentation clarification, not reporting a proven apply_patch implementation defect.

Our project workflow requires exclusive creation of new files without overwriting existing files, protection against symlink traversal, file and parent-directory fsync, and complete readback verification. These are project-specific requirements, not requirements we assume Codex imposes.

Codex successfully created four Markdown files. Subsequent checks confirmed their contents, hashes, format, permissions, and complete readback. The original completion reported successful file/parent fsync, but the later verification did not repeat those operations.

The unresolved question concerns creation-time guarantees. We could not establish from the available tool description whether apply_patch's Add File operation guarantees exclusive creation, refuses existing targets, or protects against symlink traversal and concurrent target creation.

The agent also reported that its active instructions required local file edits to use apply_patch and prohibited an alternative Python writer. We cannot independently confirm the origin or full scope of that reported restriction. Python's filesystem primitives are technically available, but availability alone does not establish permission to use them.

Could you clarify:

  1. Is an apply_patch-only restriction intended in this environment, and what is its scope?
  2. What supported tool route should be used when a project requires exclusive, non-overwriting file creation?
  3. Where are the guarantees for existing targets, target/parent symlinks, and concurrent creation documented?
  4. How should file fsync, parent-directory fsync, and symlink-safe readback be performed within the supported workflow?
  5. If these guarantees are outside apply_patch's scope, could the documentation state that explicitly and describe any supported alternative?

If a newer CLI version addresses this, please identify the version and relevant documented change. We have not verified an update as a solution.

No file corruption was found. Successful content verification is not being presented as proof of creation-time exclusivity. No project files, credentials, configuration files, or session transcripts are attached.

Where did you find it?

The uncertainty arose from the apply_patch tool description exposed in a Codex CLI 0.149.0 session and the agent's explanation of its permitted editing workflow.

Related documentation consulted:

Codex troubleshooting:
https://learn.chatgpt.com/docs/reference/troubleshooting

Codex MCP documentation:
https://learn.chatgpt.com/docs/extend/mcp?surface=cli

These pages provide reporting and extension guidance, but did not resolve the specific file-creation guarantees or the reported editing restriction. I am not identifying a particular sentence on these pages as incorrect.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the apply_patch tool description exposed by Codex CLI 0.149.0 and compare it with the Codex troubleshooting and MCP documentation linked in the issue. Trace the relevant CLI tool behavior for existing targets, symlinks, concurrent creation, and fsync support. Done means the documentation clearly states the guarantees, limitations, supported workflow, and any version-specific changes.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
cli, documentation, security
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.