Relative write rules under :workspace_roots recursively expand across turns until process spawning fails with E2BIG

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

26.707.72221 (Codex Desktop surface in the ChatGPT app; the affected session recorded embedded codex-cli 0.144.2)

What subscription do you have?

ChatGPT Pro (x20)

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

When a custom permission profile grants relative write access to .git and
.agents under :workspace_roots, Codex Desktop appears to feed the derived
permission-path entries back into the workspace-root set on subsequent turns.
The same relative rules are then applied again, synthesizing increasingly deep
path strings such as:

<repo>/.git/.agents
<repo>/.git/.git/.agents
<repo>/.agents/.git/.agents/.git

These paths are entries in Codex's permission metadata; Codex did not create
the corresponding directories on disk. The four first-level nested paths
.git/.git, .git/.agents, .agents/.git, and .agents/.agents were absent
from the affected repository's filesystem when checked.

The workspace and writable-root sets grow on each turn. Eventually all local
process creation fails, including commands with almost no arguments such as
pwd:

Failed to create unified exec process: Argument list too long (os error 7)

Restarting the app does not repair a task whose stored permission context has
already expanded. Continuing in a new task is then required unless the task can
be recovered by other means.

In one affected task, the recorded permission context grew as follows:

| Time (UTC) | Workspace roots | Writable roots | Approx. permission-context size |
| --- | ---: | ---: | ---: |
| 03:22 | 2 | 5 | 3.8 KB |
| 03:40 | 4 | 9 | 6.5 KB |
| 04:33 | 22 | 45 | 33.5 KB |
| 05:01 | 62 | 125 | 99.2 KB |
| 05:09 | 126 | 253 | 207.3 KB |

This is not caused by a long shell command. Once the task reaches the failure
state, short commands such as pwd, sed, and git diff all fail before the
shell process starts.

What steps can reproduce the bug?

1. On macOS, configure a custom permission profile that extends :workspace

and contains relative child write rules under :workspace_roots:

```toml
default_permissions = "main-workspace"

[permissions.main-workspace]
extends = ":workspace"

[permissions.main-workspace.filesystem.":workspace_roots"]
".git" = "write"
".agents" = "write"
```

1. Start a new Codex Desktop task in a Git repository with that profile.
2. Continue the same task across multiple user turns.
3. Inspect the task's recorded turn_context values for

workspace_roots and sandbox_policy.writable_roots.

1. Observe that derived permission-path entries from the preceding turn are

treated as new workspace roots and receive the same relative rules again,
even though the corresponding filesystem directories do not exist.

1. Continue until the permission context becomes large enough that a local

command fails with Argument list too long (os error 7).

The affected session used embedded codex-cli 0.144.2. A comparison task using
0.144.0-alpha.4 with the same global configuration remained bounded across 61
recorded turn contexts: writable roots never exceeded 5 and workspace roots
never exceeded 6. This comparison suggests a regression between those builds,
but does not by itself identify the exact introducing commit.

The public 0.144.2 source intentionally expands each symbolic
:workspace_roots rule into a concrete path entry for every runtime workspace
root. That path-joining operation does not create directories. The unresolved
defect is why concrete permission-path entries derived in one turn were
included in the runtime workspace-root input of later turns. The available
evidence does not yet distinguish whether Codex Desktop supplied the expanded
set again or the app-server/runtime persisted or merged the wrong set.

This configuration is not the separate permissions.<profile>.workspace_roots
table used to add workspace roots. The official configuration model and the
0.144.2 parser distinguish that root-registration table from
permissions.<profile>.filesystem.":workspace_roots", which defines filesystem
access rules inherited by the existing workspace roots. Therefore, treating
the derived .git and .agents permission entries as new workspace roots on
later turns is not the documented meaning of this configuration.

What is the expected behavior?

Relative filesystem rules under :workspace_roots should be evaluated against
the original workspace-root set for the task. Permission-path entries derived
from those rules must not be fed back as new workspace roots on the next turn.

The effective workspace and writable-root sets should remain bounded and stable
unless the user or app explicitly adds a workspace root.

Additional information

A verified workaround is to remove the relative .git and .agents write
rules from :workspace_roots and grant write access to the required directories
using explicit absolute paths instead. After applying that workaround and
restarting Codex, two consecutive turns remained stable at 11 writable roots,
with no duplicates and no nested .git/.git, .git/.agents, .agents/.git, or
.agents/.agents writable roots.

Potentially related but not duplicate reports:

• #31838 reports TUI latency with many statically configured workspace roots;

this report concerns roots generated recursively across turns until E2BIG.

• #31269 reports a custom permission profile switching after the first prompt;

this report concerns recursive path materialization while the profile is in
effect.

I have retained the affected task ID and sanitized root-count evidence and can
provide additional diagnostics through an appropriate private support channel.
No repository names, user paths, or raw task logs are included in this report.