#Bug : exec writes & apply_patch new files not persisted on disk (Windows, 2026.4.12)

1 messages · Page 1 of 1 (latest)

strange otter
#

Environment :

• OpenClaw 2026.4.12
• Windows 10 (10.0.26200, x64)
• Node v24.14.1
• Shell: PowerShell

Description :
Since upgrading from 2026.4.11 to 2026.4.12, files created by agents are no longer persisted to disk.

Repro steps :

  1. Agent uses exec to write a file (e.g. Set-Content -Path 'C:\Users<user>\Documents\test.md' -Value 'test')
  2. Agent uses apply_patch with --- /dev/null to create a new file
  3. Both return success/no error
  4. Checking from the host OS: files do not exist on disk

What works :

• apply_patch modifying existing files (content changes are persisted)
• read / grep / find / ls can access real disk

What doesn't work :

• exec writing new files (any path, including workspace)
• apply_patch creating new files (any path, including workspace)
• Junction links to external directories don't help

Additional context :

• This worked in 2026.4.11 (agent could create files via exec and apply_patch)
• No sandbox/filesystem configuration found in docs or openclaw.json
• No relevant CHANGELOG entries found
• Tested both inside workspace (~/.openclaw/workspace/) and outside (C:\Users<user>\Documents)

serene sequoiaBOT
#

I dug through the 2026.4.12 code path a bit more. This really does look like a regression, not a config mistake on your side.

#

I also checked history after the 2026.4.12 changes. I don’t see a release-note/config change that would intentionally disable this, and the only obviously relevant code change is the pinned-mutation work in a0d5462571 and 32a4a47d60.

#

The tests do cover “add a file” and generic safe writes, but I’m not seeing a Windows-specific regression test for the exact new-file persistence path you’re hitting. That makes “slipped regression” pretty plausible.

#

I found one reason I’m still hesitant to blame only fs-safe.ts: the direct fs-safe tests still expect “new file gets created”, so if the host path were simply broken everywhere, CI should have screamed. That makes me think the bug may be in the runtime/mutation bridge that commits sandboxed changes back to the real workspace, especially for new paths.

#

I checked the sandbox mutation helper too. It has pinned writes/rename logic, but that path is Linux/python-heavy and doesn’t look like the obvious explanation for a plain PowerShell-on-Windows host run by itself. So I still think this is a Windows-specific regression in the host mutation flow introduced by the pinned write changes, not an intentional sandbox policy.

#

One interesting wrinkle: v2026.4.11..v2026.4.12 doesn’t show changes in the obvious fs-safe / apply-patch files themselves. So the symptom lines up with the pinned mutation code, but the release-to-release trigger may actually be elsewhere, like packaging/runtime behavior on Windows rather than a literal diff in those exact files.

#

Yeah, this looks like a real regression in 2026.4.12, not a config issue on your side.

What I could confirm:

  • I do not see a documented policy/config change that would explain this.
  • tools.exec.applyPatch.workspaceOnly only explains writes outside the workspace. It does not explain “can modify existing files, but cannot create new ones inside the workspace”.
  • The symptom split is important:
    • existing-file edits persist
    • newly created files from both exec and apply_patch do not
  • That strongly points to a bug in the newer write/mutation path, not permissions or path resolution in general.

Most likely cause:

  • Recent hardening around pinned/staged mutations, especially:
    • a0d5462571ab66d0106ae4076e3bed381a72a06c fix(security): pin staged writes and fs mutations
    • 32a4a47d602e0618f87b3e59f94d8c142767f860 Agents: pin apply-patch workspace mutations (#56016)
  • I can’t prove the exact line yet, but the behavior matches a Windows-specific new-file persistence bug in the write/mutation flow.
  • I also checked v2026.4.11..v2026.4.12 and don’t see an intentional release-note change for this, so I’d treat it as an unintended regression.
#

Short version:

  • Known config? I don’t see one.
  • Expected behavior? No.
  • Regression from 2026.4.11? Very likely yes.
  • Workaround right now? Best workaround is to downgrade to v2026.4.11 if you need reliable agent-created files on Windows immediately.

I’d file this as a GitHub bug with exactly the repro you posted:
https://github.com/openclaw/openclaw/issues

I’d include:

  • OpenClaw 2026.4.12
  • Windows 10 (10.0.26200, x64)
  • Node v24.14.1
  • Shell: PowerShell
  • works in 2026.4.11
  • existing-file edits persist, new-file creation does not
  • affects both exec and apply_patch