#Python3 issue / lightsail setup

1 messages · Page 1 of 1 (latest)

hot creek
#

So inside my sandbox container, python3 flat out doesn't exist — it's only on the host. The file bridge (moltbot-sandbox-fs) runs inside the container and calls python3 to do its thing, but it's not there.

Fix is to install python3 inside the container, which OpenClaw would need to handle. This looks like a known gap in their fresh Lightsail setup. Worth hitting up the OpenClaw Discord — they'd probably want to know this is broken on new installs. https://discord.com/invite/clawd

In the meantime, shell writes work fine, so I'm not completely toothless. Just uglier under the hood than it should be. 🦖

gray mantleBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

bold pendantBOT
jolly micaBOT
#

Can you paste openclaw --version first?

I checked docs/source, and this does look like a real sandbox gap, not you doing something weird.

So yes, if the file bridge is calling python3 in the sandbox, missing python3 would explain exactly this, while plain shell writes can still work through a different path.

Fast workaround options:

  1. install python3 in the sandbox via setupCommand, or
  2. switch to the common sandbox image,
  3. then recreate the sandbox runtime.

If this reproduces on a fresh Lightsail install, I’d file it as a bug here: https://github.com/openclaw/openclaw/issues

#

If you paste openclaw --version and openclaw status --all, I can help narrow whether this is expected default-image behavior or a regression.

hot creek
#

OpenClaw 2026.3.23 (ccfeecb)

jolly micaBOT
#

Thanks, that helps.

On 2026.3.23, I’d treat this as bug-worthy. The docs say sandboxed runtimes need their binaries installed in-container, and the default sandbox image is pretty minimal. If the file bridge/write path depends on python3, fresh setups should not be tripping over that silently.

Immediate workaround:

agents: {
  defaults: {
    sandbox: {
      docker: {
        network: "bridge",
        setupCommand: "apt-get update && apt-get install -y python3"
      }
    }
  }
#

And yeah, I’d file a GitHub issue with:

  • version: 2026.3.23
  • fresh Lightsail install
  • python3 missing inside sandbox
  • file bridge / safe write path failing, shell writes still working

Issue link: https://github.com/openclaw/openclaw/issues

If you want, paste openclaw status --all and openclaw sandbox explain, and I can help tighten the repro text.

hot creek
#

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/ubuntu/.openclaw/openclaw.json
Bind: loopback

✓ Config: /home/ubuntu/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

  • pid 4380 ubuntu: openclaw-gateway (127.0.0.1:18789)
  • Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
    ! Tailscale: off · unknown
    error: Error: spawn tailscale ENOENT
    ✓ Skills: 5 eligible · 0 missing · /home/ubuntu/.openclaw/workspace
    ✓ Plugin compatibility (none)
    ✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

#

🦞 OpenClaw 2026.3.23 (ccfeecb) — Like having a senior engineer on call, except I don't bill hourly or sigh audibly.

Effective sandbox:
agentId: main
sessionKey: agent:main:main
mainSessionKey: agent:main:main
runtime: sandboxed
mode: all scope: session perSession: true
workspaceAccess: rw workspaceRoot: /home/ubuntu/.openclaw/sandboxes

Sandbox tool policy:
allow (default): exec, process, read, write, edit, apply_patch, image, sessions_list, sessions_history, sessions_send, sessions_spawn, sessions_yield, subagents, session_status
deny (default): browser, canvas, nodes, cron, gateway, telegram, whatsapp, discord, irc, googlechat, slack, signal, imessage, line

Elevated:
enabled: true
channel: (unknown)
allowedByConfig: false

Fix-it:

  • agents.defaults.sandbox.mode=off
  • agents.list[].sandbox.mode=off
  • tools.sandbox.tools.allow
  • tools.sandbox.tools.deny
  • agents.list[].tools.sandbox.tools.allow
  • agents.list[].tools.sandbox.tools.deny
  • tools.elevated.enabled

Docs: docs.openclaw.ai/sandbox

jolly micaBOT
#

This report is mostly clean.

Two notes:

  • Port 18789 already in use is not the problem here, it just means your gateway is already running.
  • spawn tailscale ENOENT is only relevant if you were trying to use Tailscale.

What’s missing is the sandbox runtime detail. Can you paste these next?

openclaw sandbox explain
openclaw sandbox list

Docs: https://docs.openclaw.ai/cli/sandbox and https://docs.openclaw.ai/gateway/sandboxing

If that shows the default openclaw-sandbox:bookworm-slim and no setupCommand, then your diagnosis is basically confirmed: minimal sandbox image, no python3, file bridge/write helper falls over.

#

At that point I’d call it a solid GitHub issue, with the repro:

  1. fresh Lightsail install
  2. sandbox enabled
  3. default sandbox image
  4. python3 missing in container
  5. file bridge/safe writes fail, shell writes still work

You’re pretty close, I just want the sandbox output so we can pin it down cleanly.

hot creek
#

📦 Sandbox Runtimes:

openclaw-sbx-agent-main-main-6d9217fe
Status: 🟢 running
Image: openclaw-sandbox:bookworm-slim ✓
Backend: docker
Age: 20m 28s
Idle: 11m 27s
Session: agent:main:main

Total: 1 (1 running)

jolly micaBOT
#

Yep, this basically confirms it.

Your main session is fully sandboxed (mode: all), and write/edit/apply_patch are allowed there, so those file ops are happening inside the sandbox container. If python3 is missing in that container, the failure mode you described makes sense.

Also, this bit matters:

  • Elevated: enabled: true
  • allowedByConfig: false

So elevated escape is not actually available right now.

I’d look at it like this:

  1. Recommended: keep sandboxing, switch to a sandbox image that already has python3, then run:
    openclaw sandbox recreate --all
    
#
  1. Works, but fussier: use sandbox.docker.setupCommand to install python3, but that only works if the sandbox also has:

    • network egress
    • writable root
    • root user
  2. Fastest unblock: set main to unsandboxed (mode: non-main or off), but that weakens isolation.

Docs:

At this point I’d absolutely file the bug. Suggested title:

Sandbox file writes fail on fresh Lightsail install because python3 is missing in the default sandbox container

If you want, paste openclaw sandbox list too, but honestly you already have enough for a pretty solid repro.

#

Yep, that’s the smoking gun.

You’re on the default minimal sandbox image:

  • openclaw-sandbox:bookworm-slim
  • main session is sandboxed
  • file ops run in that sandbox
  • python3 is missing there

So this looks like a real gap, not operator error.

Best workaround

  • switch to a sandbox image that includes python3, then:
    openclaw sandbox recreate --all
    
  • or unsandbox main temporarily if you just want to get unstuck fast
#

Docs:

If you file the bug, I’d use this title:

Fresh Lightsail install: sandbox file writes fail because default openclaw-sandbox:bookworm-slim image lacks python3

And a short repro like:

OpenClaw 2026.3.23 (ccfeecb)

Fresh Lightsail install.
Main session is sandboxed (`mode: all`).
Sandbox runtime uses `openclaw-sandbox:bookworm-slim`.