Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Docker sandboxed agents have no access to workspace with SELinux [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#58019•Fetched 2026-04-08 01:54:50
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
mobilinkdmobilinkd
Participants
mobilinkdmobilinkd
Timeline (top)
labeled ×2closed ×1cross-referenced ×1locked ×1

Docker sandboxed agents always receive EACCESS when accessing files in their workspace when SELinux is enforcing.

Root Cause

Docker sandboxed agents always receive EACCESS when accessing files in their workspace when SELinux is enforcing.

Fix Action

Fix / Workaround

        "tools": {
          "allow": ["browser", "read", "write", "apply_patch"],
        },
        "sandbox": {
          "workspaceAccess": "rw"
        }

PR fix notes

PR #58025: Sandbox: relabel managed workspace mounts for SELinux

Description (problem / solution / changelog)

Summary

  • Fixes #58019 by relabeling OpenClaw-managed sandbox workspace binds so SELinux-enforcing hosts can mount them inside containers.
  • Recreate stale sandbox browser containers when the managed mount format changes, so they do not keep broken bind options.
  • Add focused regression coverage for mount formatting/versioned hash behavior and extend sandbox create-args expectations.

Repro Steps

  1. Enable Docker sandboxing on an SELinux-enforcing host.
  2. Start a sandboxed agent with workspace access.
  3. Observe EACCES inside the container when reading workspace files.
  4. Recreate the sandbox containers with this patch and verify workspace reads succeed.

Root Cause

  • OpenClaw emitted plain managed bind mounts (host:container or :ro) for sandbox workspaces.
  • SELinux-enforcing hosts require relabeling on those binds, and the workspace can be shared by both the main sandbox and browser sidecar.
  • Existing browser sidecars had no mount-format recreation signal, so they could keep stale bind options after the fix landed.

Behavior Changes

  • Managed sandbox workspace binds now use :z or :ro,z.
  • The sandbox config hash now includes a mount-format version so main containers recreate or warn consistently.
  • Sandbox browser containers now detect outdated mount-format labels and recreate before use.
  • User-specified extra sandbox.docker.binds are left unchanged.

Codebase and GitHub Search

  • Searched the codebase for SELinux, :z, :Z, workspaceAccess, docker, and sandbox.
  • Reviewed src/agents/sandbox/docker.ts, src/agents/sandbox/browser.ts, src/agents/sandbox/config-hash.ts, and current sandbox docs.
  • Compared current behavior against #58019.

Tests

  • pnpm exec oxlint --type-aware src/agents/sandbox/docker.ts src/agents/sandbox/browser.ts src/agents/sandbox/config-hash.ts src/agents/sandbox/mounts.ts src/agents/sandbox/mounts.test.ts src/agents/sandbox-create-args.e2e.test.ts
  • pnpm exec oxfmt --check src/agents/sandbox/docker.ts src/agents/sandbox/browser.ts src/agents/sandbox/config-hash.ts src/agents/sandbox/mounts.ts src/agents/sandbox/mounts.test.ts src/agents/sandbox-create-args.e2e.test.ts
  • node --import tsx -e "..." direct validation for managed mount formatting and the mount-format hash bump
  • pnpm check currently fails in this checkout because oxfmt --check reports existing repo-wide formatting drift across many unrelated files
  • pnpm build currently fails in this checkout in vendor/a2ui (node:assert / node:test typings)
  • pnpm test / targeted Vitest runs currently fail before suite execution because of an unrelated getOAuthProviders is not a function auth-profile import/runtime error

Manual Testing

  • N/A on this macOS host; no SELinux runtime is available locally.

Prerequisites

  • Docker sandboxing enabled
  • SELinux-enforcing host to reproduce the original bug

Steps

  1. Configure a sandboxed agent with workspaceAccess: \"rw\" or \"ro\" on an SELinux-enforcing host.
  2. Trigger sandbox creation or run openclaw sandbox recreate --all / openclaw sandbox recreate --browser.
  3. Verify the managed binds include :z / :ro,z and workspace reads succeed inside both sandbox and sandbox-browser containers.

Evidence

  • Related issue: #58019
  • lobster-biscuit

Sign-Off

  • Models used: Cursor
  • Submitter effort: targeted patch plus local validation
  • Agent notes: AI-assisted implementation and review. User-specified extra binds were intentionally left untouched because auto-relabeling arbitrary mounts like docker.sock would be riskier.

Made with Cursor

Changed files

  • src/agents/sandbox/browser.create.test.ts (modified, +18/-4)
  • src/agents/sandbox/browser.ts (modified, +5/-3)
  • src/agents/sandbox/config-hash.test.ts (modified, +33/-0)
  • src/agents/sandbox/config-hash.ts (modified, +2/-0)
  • src/agents/sandbox/docker.config-hash-recreate.test.ts (modified, +30/-4)
  • src/agents/sandbox/docker.ts (modified, +3/-1)
  • src/agents/sandbox/workspace-mounts.test.ts (modified, +22/-5)
  • src/agents/sandbox/workspace-mounts.ts (modified, +20/-7)

Code Example

"tools": {
          "allow": ["browser", "read", "write", "apply_patch"],
        },
        "sandbox": {
          "workspaceAccess": "rw"
        }

---

Here is the output of the `docker exec` showing that it is an SELinux problem.

$ sudo setenforce 0
$ docker exec 54aef0ad1e2d ls
AGENTS.md
HEARTBEAT.md
IDENTITY.md
MEMORY.md
SOUL.md
TOOLS.md
USER.md
memory
skills
$ sudo setenforce 1
$ docker exec 54aef0ad1e2d ls
ls: cannot open directory '.': Permission denied
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Docker sandboxed agents always receive EACCESS when accessing files in their workspace when SELinux is enforcing.

Steps to reproduce

  1. Start OpenClaw 2026.3.28 (f9b1079) on a Linux machine with SELinux in enforcing mode.
  2. Create a docker sandboxed agent with read/write permission and tools.
  3. Ask the agent to read their files: "What is the content of SOUL.md using only the read function."
  4. Run docker ps to find the container ID of the agent.
  5. Run docker exec $CONTAINER_ID ls
        "tools": {
          "allow": ["browser", "read", "write", "apply_patch"],
        },
        "sandbox": {
          "workspaceAccess": "rw"
        }

Expected behavior

The agent should be able read their files.

docker exec CONTAINER_ID ls should return the sandboxed workspace contents.

Actual behavior

The agent responds with "I can't read files or access file contents. However, I can help you understand how to read files or provide guidance on file operations if you'd like. Let me know how you'd like to proceed!"

docker exec CONTAINER_ID ls results in ls: cannot open directory '.': Permission denied.

OpenClaw version

2026.3.28

Operating system

Fedora 43

Install method

curl -fsSL https://openclaw.ai/install.sh | bash

Model

nemotron-3-super:cloud

Provider / routing chain

openclaw -> ollama -> ollama cloud

Additional provider/model setup details

This is model agnostic.

Logs, screenshots, and evidence

Here is the output of the `docker exec` showing that it is an SELinux problem.

$ sudo setenforce 0
$ docker exec 54aef0ad1e2d ls
AGENTS.md
HEARTBEAT.md
IDENTITY.md
MEMORY.md
SOUL.md
TOOLS.md
USER.md
memory
skills
$ sudo setenforce 1
$ docker exec 54aef0ad1e2d ls
ls: cannot open directory '.': Permission denied

Impact and severity

Affected: All SELinux users with sandboxed agents Severity: Sandboxing is impossible on SELinux Frequency: Always Consequence: Impossible to run sandboxed agents under SELinux

Additional information

This made the basic recommended secure setup on Fedora impossible. Following many online guides step-by-step resulted in a non-functional agent as they could never get through the BOOTSTRAP process.

There appears to be another problem, as the gateway seems to inject the files from workspaceDir, not from sandboxes/agent-<name>-<id>, but I don't have enough experience with OpenClaw to know if this is intentional.

extent analysis

Fix Plan

To resolve the issue of Docker sandboxed agents receiving EACCESS when accessing files in their workspace under SELinux, follow these steps:

  • Disable SELinux enforcement for the Docker container or set a specific SELinux policy for the container to allow file access. However, disabling SELinux enforcement might not be desirable for security reasons.
  • Use SELinux labels to allow the container to access the workspace directory. This involves setting the correct SELinux context for the workspace directory and ensuring that the Docker container is allowed to access directories with that context.
  • Modify the Docker container's SELinux policy to include the necessary rules for accessing the workspace directory.

Example code to set the SELinux context for the workspace directory:

sudo chcon -Rt svirt_sandbox_file_t /path/to/workspace

To permanently set the SELinux context, use semanage:

sudo semanage fcontext -a -t svirt_sandbox_file_t /path/to/workspace

Then, reload the SELinux policy:

sudo restorecon -R /path/to/workspace

Verification

After applying the fix, verify that the Docker container can access the workspace directory by running:

docker exec $CONTAINER_ID ls

This should list the contents of the workspace directory without any permission errors.

Extra Tips

  • Ensure that the SELinux policy is correctly configured to allow the Docker container to access the necessary directories.
  • Consider using a tool like audit2allow to generate SELinux policies based on the audit logs.
  • Be cautious when modifying SELinux policies, as incorrect configurations can lead to security vulnerabilities.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The agent should be able read their files.

docker exec CONTAINER_ID ls should return the sandboxed workspace contents.

#tool integration#LLM response#prompt template#agent execution#callback error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Docker sandboxed agents have no access to workspace with SELinux [1 pull requests, 1 participants]