Bug type
Regression (worked before, now fails)
Summary
Sandbox file-tool edits rewrite host-mounted workspace files with mode 060 (and ownership follows the sandbox writer UID), causing normal OpenClaw file tools to fail with EACES.
Steps to reproduce
- Run OpenClaw with Docker sandbox enabled and a writable mounted workspace.
- Configure the sandbox user, then recreate/remove the sandbox container so the setting actually applies.
- From inside the sandbox, create a file in
/workspace, for example:
printf 'hello\n' > /workspace/permtest.txt
stat -c '%u %g %a %n' /workspace/permtest.txt
- Use the OpenClaw edit tool on that same file.
- Check file ownership/mode again with stat.
- Try reading the file via the normal OpenClaw read tool.
Expected behavior
Editing a workspace file from the sandbox should preserve sane accessibility for the normal OpenClaw file tools. At minimum, the file should remain readable/writable by the workspace owner and should not be rewritten to restrictive mode 060 unless it already had that mode.
Actual behavior
After a successful edit, the file mode collapses to 060, and ownership follows the active sandbox writer UID.
Observed in a uid-mapped sandbox:
id
# uid=100 gid=100 groups=100
printf 'restart-test\n' > /workspace/restart-permtest.txt
stat -c '%u %g %a %n' /workspace/restart-permtest.txt
# 100 644 /workspace/restart-permtest.txt
``
After OpenClaw `edit`:
```bash
stat -c '%u %g %a %n' /workspace/restart-permtest.txt
# 100 600 /workspace/restart-permtest.txt
``
Observed in a root sandbox:
```bash
id
# uid=0(root) gid=0(root) groups=0(root)
printf 'post-recreate\n' > /workspace/postrecreate-permtest.txt
stat -c '%u %g %a %n' /workspace/postrecreate-permtest.txt
# 0 644 /workspace/postrecreate-permtest.txt
``
After OpenClaw `edit`:
```bash
stat -c '%u %g %a %n' /workspace/postrecreate-permtest.txt
# 0 600 /workspace/postrecreate-permtest.txt
``
Once a file is in that state, normal OpenClaw file tools fail on the host-side bridge path:
```text
EACES: permission denied, open '/home/patrick/.openclaw/workspace/root600-test.txt'
EACES: permission denied, open '/home/patrick/.openclaw/workspace/TOOLS.md'
``
### OpenClaw version
2026.3.8
### Operating system
Fedora 42
### Install method
npm global
### Model
openai-codex/gpt-5.4
### Provider / routing chain
openclaw -> openai-codex -> gpt-5.4
### Config file / key location
~/.openclaw/openclaw.json
### Additional provider/model setup details
This does not appear model-specific. The bug reproduces in the sandbox/file-tool write path regardless of model output. Relevant context is the Docker sandbox configuration and mounted workspace behavior.
### Logs, screenshots, and evidence
```shell
# uid-mapped sandbox case
id
uid=100 gid=100 groups=100
printf 'restart-test\n' > /workspace/restart-permtest.txt
stat -c '%u %g %a %n' /workspace/restart-permtest.txt
100 100 644 /workspace/restart-permtest.txt
# after edit tool
stat -c '%u %g %a %n' /workspace/restart-permtest.txt
100 100 600 /workspace/restart-permtest.txt
# root sandbox case
id
uid=0(root) gid=0(root) groups=0(root)
printf 'post-recreate\n' > /workspace/postrecreate-permtest.txt
stat -c '%u %g %a %n' /workspace/postrecreate-permtest.txt
0 0 644 /workspace/postrecreate-permtest.txt
# after edit tool
stat -c '%u %g %a %n' /workspace/postrecreate-permtest.txt
0 0 600 /workspace/postrecreate-permtest.txt
# host-side file tool failures
EACES: permission denied, open '/home/patrick/.openclaw/workspace/root600-test.txt'
EACES: permission denied, open '/home/patrick/.openclaw/workspace/TOOLS.md'
``
Impact and severity
Affected: anyone using sandboxed file tools against a host-mounted writable workspace
Severity: High
Frequency: 100% reproducible in local testing
Consequence: successful edits can render workspace files unreadable to normal OpenClaw file tools; files may become root:root 060 in root sandboxes or 100:100 060 in uid-mapped sandboxes, breaking subsequent read/edit workflows
Additional information
This appears distinct from, but related to, #20979.
The evidence suggests the sandbox/file-tool write path is performing an atomic replace using a newly created temp file whose mode ends up as 060. Ownership then follows the writer UID:
- root sandbox ->
root:root 060
- uid-mapped sandbox ->
100:100 060
So even when write access itself works, the resulting file metadata is still wrong.
Temporary workaround: manually chown/chmod affected files after edits. Last known good version is unknown; first clearly observed during testing on 2026.3.8.
Bug type
Regression (worked before, now fails)
Summary
Sandbox file-tool edits rewrite host-mounted workspace files with mode
060(and ownership follows the sandbox writer UID), causing normal OpenClaw file tools to fail withEACES.Steps to reproduce
/workspace, for example:Expected behavior
Editing a workspace file from the sandbox should preserve sane accessibility for the normal OpenClaw file tools. At minimum, the file should remain readable/writable by the workspace owner and should not be rewritten to restrictive mode
060unless it already had that mode.Actual behavior
After a successful
edit, the file mode collapses to060, and ownership follows the active sandbox writer UID.Observed in a uid-mapped sandbox:
Impact and severity
Affected: anyone using sandboxed file tools against a host-mounted writable workspace
Severity: High
Frequency: 100% reproducible in local testing
Consequence: successful edits can render workspace files unreadable to normal OpenClaw file tools; files may become
root:root 060in root sandboxes or100:100 060in uid-mapped sandboxes, breaking subsequent read/edit workflowsAdditional information
This appears distinct from, but related to, #20979.
The evidence suggests the sandbox/file-tool write path is performing an atomic replace using a newly created temp file whose mode ends up as
060. Ownership then follows the writer UID:root:root 060100:100 060So even when write access itself works, the resulting file metadata is still wrong.
Temporary workaround: manually
chown/chmodaffected files after edits. Last known good version is unknown; first clearly observed during testing on 2026.3.8.