Regression: :workspace_roots write rules recursively expand again on 0.147.0

Regression context

This is a regression follow-up to #33479, which was closed after the original configuration remained stable in tests on 0.145.0 and 0.146.1.

The same recursive permission-root feedback-loop signature has now reproduced again on a current installation reporting codex-cli 0.147.0.

Additional evidence was posted on the closed report: https://github.com/openai/codex/issues/33479#issuecomment-5228570234

Environment

• Codex CLI reported by codex doctor: 0.147.0
• Platform: macOS 26.6.1, arm64
• Approval policy: on request
• Filesystem sandbox: restricted
• config.toml parse: OK
• Sandbox configuration: readable

Triggering configuration

The active custom permission profile contains the same relative write rules as the original report:

default_permissions = "repo-dev"

[permissions.repo-dev.filesystem.":workspace_roots"]
"." = "write"
".git" = "write"
".agents" = "write"

There were no configuration changes between the two diagnostic snapshots.

Observed behavior

| Metric | First snapshot | Second snapshot | Change |
|---|---:|---:|---:|
| Workspace roots | 2 | 34 | +32 |
| Writable roots | 38 | 102 | +64 |
| Unique root union | 38 | 102 | +64 |
| Minimal pwd spawn | 0.061 s | 5.886 s | ~97× slower |

Previously generated writable paths were promoted into the workspace-root set on the next turn. The relative .git and .agents rules were then applied to those generated roots, producing another suffix layer.

Representative synthetic permission paths included:

.agents/.agents/.agents
.agents/.git/.git
.codex/config.toml/.agents
.codex/config.toml/.git

These were permission metadata entries, not corresponding directories created on disk.

The shell still worked in the second snapshot, but minimal process startup had already increased from 61 milliseconds to 5.9 seconds. Continuing the affected task risks reaching the previously reported E2BIG / Argument list too long failure state.

Control observation

A fresh Desktop task using its managed five-entry permission profile remained stable across three saved turn contexts:

• 2 workspace roots
• 1 sandbox writable root
• 0 suspicious nested roots
• normal process spawning

That control does not exercise the custom repo-dev profile. It supports the same conditional trigger as #33479 rather than a global shell or malformed-config failure.

Steps to reproduce

1. Configure a custom permission profile with relative .git and .agents write rules under filesystem.":workspace_roots".
2. Fully restart Codex.
3. Start a fresh task using that custom profile.
4. Continue the same task through at least two user turns without changing the configuration or workspace.
5. Compare the saved turn_context values for workspace_roots, writable roots, and effective permission paths.
6. Observe generated write paths being promoted into the next turn's workspace roots and receiving an additional suffix layer.
7. Continue until command startup becomes slow or fails before the requested process begins.

Expected behavior

Relative rules under :workspace_roots should be evaluated only against the original runtime workspace-root set. Derived permission paths must not be persisted or promoted as workspace roots on subsequent turns.

Root sets and the serialized permission profile should remain bounded across unchanged turns.

Additional information

A search of currently open openai/codex issues did not find another report covering this exact recursive root-growth and E2BIG failure mode.

This issue is intentionally filed as a regression follow-up because #33479 is closed as completed while the same measured failure signature has returned.