### What feature would you like to see? Support direct file read/write APIs (e.g. readFile/writeFile) instead of relying on shell commands for filesystem access. ### Additional information ### Additional context - Using PowerShell/bash commands for file I/O leads to multiple cross-platform issues: - CRLF vs LF line endings - Encoding mismatches (UTF-8 vs system codepages) - Shell escaping for paths with spaces/special characters - Inconsistent behavior across Windows / macOS / Linux

Support direct file read/write APIs instead of shell commands

Resolved 💬 4 comments Opened Jan 25, 2026 by dismonjames Closed Mar 20, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What feature would you like to see?

Support direct file read/write APIs (e.g. readFile/writeFile) instead of relying on shell commands for filesystem access.

Additional information

Additional context

Using PowerShell/bash commands for file I/O leads to multiple cross-platform issues:
CRLF vs LF line endings
Encoding mismatches (UTF-8 vs system codepages)
Shell escaping for paths with spaces/special characters
Inconsistent behavior across Windows / macOS / Linux

Why it matters

Agents and tools often need to write multi-line files (source code, configs, serialized data)
Shell-based writes easily corrupt or reformat content unintentionally
Beginners struggle with shell quirks → worse onboarding UX

Proposed direction

Introduce a direct file API surface (e.g. readFile, writeFile, appendFile)
Ensure consistent behavior across CLI and other Codex surfaces
Avoid shell entirely for non-interactive filesystem operations

Willing to contribute

I’m interested in contributing a prototype implementation (especially Windows support).
Happy to help with API design, cross-platform behavior, and testing.

View original on GitHub ↗

4 Comments

etraut-openai contributor · 7 months ago

Codex already includes an apply_patch tool that is an advanced version of what you're describing here. There are times when apply_patch is optimal. There are other times when it's more efficient for the model to use other techniques (other tools, small shell scripts, Python scripts, etc.) to get the job done.

dismonjames · 7 months ago

Thanks for the context!

I’m aware of the apply_patch tool and I agree it’s a good fit for many edit-style operations. The pain point I’m running into is specifically around full file creation/overwrite on Windows when going through shell commands:

CRLF/LF line ending issues when writing multi-line content
Encoding / codepage quirks in PowerShell
Escaping/quoting problems for longer payloads

apply_patch is great when you already have a file on disk and you’re applying a diff, but for flows like:

creating a brand-new file from scratch
rewriting most of a file’s contents
generating multiple files in one shot

shell-based I/O still tends to introduce subtle corruption or formatting problems.

I’m not asking to remove or replace shell-based tools — they’re clearly useful in many scenarios. What I’m proposing is a complementary, direct file read/write surface (e.g. readFile / writeFile / appendFile) that Codex can choose when it needs a “safe, binary-free, cross-platform” path for text files, especially on Windows.

If that general direction sounds reasonable, I’m happy to put together a small design/PR sketch for how this could look in the CLI first and keep it opt-in / backward-compatible. Would that be in scope for the roadmap?

etraut-openai contributor · 7 months ago

The apply_patch tool is already a safe, binary-free, cross-platform path for text files.

I don't think the problems you're describing would be solved by a direct read/write tool. Those are model behaviors, so improvements will need to be trained in to future versions of the model.

etraut-openai contributor · 5 months ago

This feature request hasn't received enough upvotes, so closing.