workspace-write cannot edit .agents/skills/** inside trusted workspace, but danger-full-access can
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.409.20454 (1462)
What subscription do you have?
100$
What platform is your computer?
Darwin 24.6.0 arm64 arm
What issue are you seeing?
In workspace-write mode, Codex can read files under .agents/skills/** but cannot write them, even though they are inside a trusted workspace.
The same edit succeeds immediately in danger-full-access, and other workspace files remain writable in workspace-write.
This makes repo-local skills unusable as living documents during normal development.
What steps can reproduce the bug?
- Open a trusted local workspace repo.
- Ensure Codex is running in
workspace-writemode. - Ask Codex to edit a skill file inside the workspace, for example:
.agents/skills/skill-creator/SKILL.md
- Codex attempts either:
apply_patch, or- a direct file write using Node
- The write fails.
I reproduced both failure modes.
apply_patch failure:patch rejected: writing outside of the project; rejected by user approval settings
Direct write failure:Error: EPERM: operation not permitted, open '.agents/skills/skill-creator/SKILL.md'
What is the expected behavior?
Expected
Files under .agents/skills/** are inside the trusted workspace root and should be writable in workspace-write, just like other files in the repo.
Actual
Codex can read files under .agents/skills/**, but cannot write them in workspace-write.
The same write succeeds immediately if I switch the session to danger-full-access.
Additional information
I verified all of the following locally:
- Writing to repo-root files succeeds in
workspace-write - Writing to
/tmpsucceeds - Writing to another hidden directory in the same repo succeeds
- Writing specifically under
.agents/**fails inworkspace-write - The exact same skill-file write succeeds in
danger-full-access
So this appears to be a path-specific sandbox issue for .agents/**, not a general filesystem permission problem.
My Codex config includes:
model = "gpt-5.4"
profile = "backend_auto"
sandbox_mode = "workspace-write"
approval_policy = "on-request"
[sandbox_workspace_write]
network_access = true
[profiles.backend_auto]
sandbox_mode = "workspace-write"
approval_policy = "never"
[projects."/path/to/repo"]
trust_level = "trusted"
OpenAI’s docs say repo-local skills live under .agents/skills, so this path appears intended to be part of normal editable workspace content:
https://developers.openai.com/codex/skills
This is a workflow blocker because repo-local skills are living documents that need to be updated during normal work.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Update after more local testing: my original diagnosis was incomplete.
The active profile in my config was
backend_auto, and that profile set:sandbox_mode = "workspace-write"approval_policy = "never"After switching the approval policy to
on-request, I retried the exact same edit to.agents/skills/skill-creator/SKILL.mdunderworkspace-write, and it succeeded.So this is not a general case of
.agents/skills/**being uneditable inworkspace-write.What seems to be happening instead is:
workspace-write+approval_policy = "never", the skill-file edit fails outrightapply_patch:writing outside of the project; rejected by user approval settingsEPERMworkspace-write+approval_policy = "on-request", the same skill-file edit worksSo the real bug may be an interaction between
approval_policy = "never"and writes to these skill files, and/or incorrect error reporting that made this look like a path-writability bug.Leaving this here so maintainers don’t chase the wrong root cause.
```
the resulting error messages are misleading:
direct write: EPERM