Ambiguous cwd prompt serialization breaks file creation when a directory name is a single space

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

Version 26.318.11754 (1100)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

When the current working directory includes a path component named exactly " ", Codex can create a file in the parent directory with a leading space in the filename instead of creating it inside the " " directory.

This looks like prompt/context serialization ambiguity rather than a low-level filesystem join bug.

Observed in the Codex App on macOS; suspected root cause is shared prompt/context serialization in codex-rs/core, so this may also affect CLI flows.

What steps can reproduce the bug?

Platform: macOS

1. Create a directory whose name is a single space:

``sh
mkdir "/Users/name/Desktop/ "
cd "/Users/name/Desktop/ "
``

1. In Codex, ask it to create a file named foobar.py.

1. Observe the created path.

Result

Codex created:

/Users/name/Desktop/ foobar.py

What is the expected behavior?

Codex should have created:

/Users/name/Desktop/ /foobar.py

Additional information

The likely issue is that the cwd is injected into model-visible context as raw text, which makes a trailing-space path component visually ambiguous.

Relevant spots:

• codex-rs/core/src/environment_context.rs
• serializes cwd as <cwd>{cwd}</cwd>
• codex-rs/core/src/realtime_context.rs
• renders Current working directory: ...
• renders Working directory name: ...
• codex-rs/core/src/codex.rs
• passes turn_context.cwd.to_string_lossy() into contextual instructions
• codex-rs/core/src/instructions/user_instructions.rs
• renders # AGENTS.md instructions for {directory}

For a cwd like:

/Users/name/Desktop/ 

the model sees a raw string where the final path component is visually indistinguishable from a trailing space, and can infer:

/Users/name/Desktop/ foobar.py

instead of understanding that " " is its own directory component.

What I Checked

This does not appear to be a filesystem join bug. The write-path code I checked uses normal path APIs rather than manual string concatenation.

Fix Recommendation

A low-risk fix would be to disambiguate model-visible path rendering in the prompt/context layer.

Suggested approach:

• Keep the existing raw cwd field for compatibility.
• Add an explicit literal or escaped form when the path is ambiguous, especially for components with leading or trailing whitespace.

For example:

<environment_context>
  <cwd>/Users/name/Desktop/ </cwd>
  <cwd_literal>"/Users/name/Desktop/ "</cwd_literal>
  <cwd_name_literal>" "</cwd_name_literal>
</environment_context>

And similarly in realtime text:

Current working directory: /Users/name/Desktop/ 
Current working directory (literal): "/Users/name/Desktop/ "
Working directory name (literal): " "

This should preserve existing behavior while making whitespace-only path components unambiguous to the model.

Regression Test Idea

Add coverage for a cwd ending in / and verify that generated file paths target:

.../ /filename

rather than:

.../ filename