#───Bug: sandbox FS bridge fails with python3 not found after 2026.4.14 updateVersion: 2026.4.14

1 messages · Page 1 of 1 (latest)

obtuse turret
#

Version: 2026.4.14 (323493f)
OS: Ubuntu, Linux 6.17.0-1007-aws (x64), Lightsail VPS
Node: v22.22.2

Problem:
File write tool is completely broken. The sandbox FS bridge can't find Python even though it's installed on the host at /usr/bin/python3 (3.12.3).

Errors seen:

• moltbot-sandbox-fs: 2: python3: not found (first seen after update)
• sandbox pinned mutation helper requires python3 or python (after gateway restart)

Steps to reproduce:

  1. Update to 2026.4.14 via sudo npm update -g openclaw
  2. Run openclaw doctor --fix, then openclaw gateway restart
  3. Any file write from the agent fails with the above errors

Impact:
Agent can read files but cannot write, edit, or update any workspace files. Heartbeat state, memory, and daily notes all broken.

Host Python:

$ which python3
/usr/bin/python3
$ python3 --version
Python 3.12.3

feral snowBOT
sterile plinthBOT
#

Let me verify this against the current docs and source so I don't guess.

#

I found the relevant code path. It does look like a real regression, not user error. Let me trace the exact workaround path before I tell you to do something dumb.

#

I think this is a real bug, and the key detail is this:

write/edit do not use host Python directly. They use a Python helper inside the active sandbox runtime.

I checked the docs and current source:

  • read can still work while write/edit fail, because reads use a different path
  • local sandbox writes go through the pinned mutation helper
  • current SSH/OpenShell remote bridge still has a python3 shell invocation in src/agents/sandbox/remote-fs-bridge.ts

So which python3 on the VPS host is not enough to prove the sandbox can see Python.

Most likely case, Docker sandbox

If your backend is docker, this usually means the actual sandbox image/container does not have Python, even if the host does.

Please run:

# 
openclaw config get agents.defaults.sandbox.backend
openclaw sandbox list
docker run --rm --entrypoint python3 openclaw-sandbox:bookworm-slim --version

If that last command fails, rebuild the sandbox image, then recreate sandboxes:

# from an OpenClaw repo checkout
scripts/sandbox-setup.sh
openclaw sandbox recreate --all
openclaw gateway restart

Docs:

#

This also matches a previously reported bug pretty closely:
https://github.com/openclaw/openclaw/issues/57713

If your backend is ssh or openshell

Then I think you may be hitting a separate regression. The remote FS bridge still shells out to bare python3, so a stripped non-login PATH can break writes even when /usr/bin/python3 exists.

If openclaw config get agents.defaults.sandbox.backend returns ssh or openshell, paste that plus openclaw status --all, and I’d treat this as a GitHub issue candidate.

So, short version:

  • Docker backend: likely stale/bad sandbox image, rebuild + recreate
  • SSH/OpenShell backend: likely real bridge bug, not your host Python

If you paste the backend value, I can narrow it down fast.

obtuse turret
#

This issue has been fixed