Skip to content

fix(agent): a fenced folder no longer closes folders that start with its name - #255

Merged
httpsphl merged 1 commit into
mainfrom
fix/codex-fence-sibling-names
Oct 11, 2026
Merged

httpsphl merged 1 commit into
mainfrom
fix/codex-fence-sibling-names

Conversation

@httpsphl

Copy link
Copy Markdown
Owner

A real Codex run found that the fence matched folders by text: with crews Suite and Suite2, an agent in Suite2 had its edits refused without a card. The folder name now has to end where the fenced path ends (Suite2, Suite.old are other folders).

Spec 30.4 records what was seen with the real Codex (suggest_bot, browser, desktop without a grant, messages and tasks, deny/allow, plan mode) and the findings on reads: a permission profile needs the elevated Windows sandbox and breaks new folders, so reads stay open.

Checks: unit test for look-alike names; cargo clippy/fmt pass.

Manual step: with two crews named like Docs and Docs 2, ask a Codex agent in the second to create a file and see the approval card.

…its name

The Codex fence matched by text, so a crew named Suite fenced
Suite2\Ana and the agent's edits there were refused without a card.
The folder name has to end where the fence ends. Spec 30.4 records what
was seen with the real Codex on 2026-10-10, and that file reads stay
open.
@httpsphl
httpsphl merged commit 82166b7 into main Oct 11, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant