Limiting access for tools in a safer way

Question

I have started to do a bit of research on how there could be limitations put in place on what tools and commands are allowed to do during execution.

I'm still very new to the code-base so will probably miss obvious things, but here we go.

I'm thinking of implementing a interface that would run tools within a security-context. bubblewrap would be used on linux.
This would be configured on a per agent-basis similar to the current permissions part, but with a lot more control.
When launching anything it would then run in a context that could be locked down to just the content it's allowed to touch. We can set per-folder read/write permissions and prevent it from even reading files outside the project-root or even prevent a agent from doing any network-communication, like curl.

A documentation-agent could then be configured similar to:

readOnlyPaths: [ "<project root>/" ]
writeablePaths: [ "<project root>/doc", "<project root>/temp" ]
allowedExecutables: [ "/usr/bin/bash", "/usr/bin/ls", "/usr/bin/curl" ]

And this would then prevent access to anything outside of <project root> and only allow access to specific commands.
If we would do a

readOnlyPaths: [ "<project root>/" ]
writeablePaths: [ "<project root>/doc", "<project root>/temp" ]
allowedExecutables: [ "/usr/bin/bash", "/usr/bin/ls", "/usr/bin/curl", "<project root>/test-script.sh" ]

then even the test-script.sh would not be able to execute anything not included in the allowedExecutables or write outside of the specified writablePath's.

This is just a initial concept that i would like some feedback on before writing any code.

This issue might be a duplicate of existing issues. Please check:

[FEATURE] add exec tool as more secure alternative to bash tool #2206: [FEATURE] add exec tool as more secure alternative to bash tool - proposes a secure alternative to bash that prevents shell operators and discusses broader sandboxing solutions
Is there a way to sandbox the agent ? #2242: Is there a way to sandbox the agent? - asks about restricting terminal commands and file access outside the current directory, mentions seatbelt and similar sandboxing tools
Add pattern-based directory access restrictions to prevent verbose per-tool configurations #3585: Add pattern-based directory access restrictions to prevent verbose per-tool configurations - proposes pattern-based access restrictions as a global configuration option (CLOSED)

Feel free to ignore if none of these address your specific case.

@pakar

Hi @pakar, I solved this by using a slightly modified script from what I suggested in #2242 (comment).

The script is using Nix and Devbox but you can update it to your needs. Maybe this helps!

#!/usr/bin/env bash

# Define your workspace directories
WORKSPACES=(
    "/nix"
    "$PWD/devbox"
    "$PWD/.venv"
    "$PWD"
    "$PWD/node_modules"
)

# Build workspace bind mounts
WORKSPACE_BINDS=()
for ws in "${WORKSPACES[@]}"; do
    if [ -d "$ws" ]; then
        WORKSPACE_BINDS+=(--bind "$ws" "$ws")
    fi
done

# Execute OpenCode in sandbox
bwrap \
    --unshare-all \
    --share-net \
    --die-with-parent \
    --new-session \
    \
    `# Basic filesystem structure` \
    --ro-bind /usr /usr \
    --ro-bind /lib /lib \
    --ro-bind /lib64 /lib64 \
    --ro-bind /bin /bin \
    --ro-bind /sbin /sbin \
    --proc /proc \
    --dev /dev \
    --tmpfs /tmp \
    --tmpfs /run \
    \
    `# SSL certificates for API access` \
    --ro-bind-try /etc/ssl /etc/ssl \
    --ro-bind-try /etc/ca-certificates /etc/ca-certificates \
    \
    `# Home directory structure` \
    --dir "$HOME" \
    --setenv HOME "$HOME" \
    --chdir "$PWD" \
    \
    `# OpenCode config and cache directories (read-write)` \
    --bind-try "$HOME/.cache/opencode" "$HOME/.cache/opencode" \
    --bind-try "$HOME/.local/share/opencode" "$HOME/.local/share/opencode" \
    --bind-try "$HOME/.local/state/opencode" "$HOME/.local/state/opencode" \
    --bind-try "$HOME/.config/opencode" "$HOME/.config/opencode" \
    \
    `# Workspace directories (read-write)` \
    "${WORKSPACE_BINDS[@]}" \
    \
    `# Terminal and environment` \
    --setenv TMPDIR /tmp \
    --setenv PATH "$PWD/node_modules/.bin:$PWD/bin:/usr/local/bin:/usr/bin:/bin" \
    \
    `# Run OpenCode` \
    opencode "$@"

@redtux

@redtux: does this allow OpenCode to use Wayland and the GPU?

@tredondo

@redtux: does this allow OpenCode to use Wayland and the GPU?

Hi @tredondo, I am using Wayland and it works. What exactly do you mean regarding GPU? I am using AMD Ryzen Pro 7 with Ollama and ROCm, and this works fine - in case you're referring to this. Anything else I don't know how to test, but I also don't know why it should be restricted in the first place. If you can give me some hints, I'll be happy to test it.

Just in case: In other threads there are suggestions for more ways of sandboxing that might be better tested. This here was just some kind of POC to show that the same kind of abstraction and security that Claude Code offers can be realized with little to none efforts or special skills…

@redtux

@redtux I have an NVidia laptop GPU and had to add the following parameters (thanks Claude) for OpenCode to be able to use it:

    # GPU / OpenGL
    --dev-bind /dev/dri /dev/dri
    --dev-bind-try /dev/nvidia0 /dev/nvidia0
    --dev-bind-try /dev/nvidia1 /dev/nvidia1
    --dev-bind-try /dev/nvidiactl /dev/nvidiactl
    --dev-bind-try /dev/nvidia-modeset /dev/nvidia-modeset
    --dev-bind-try /dev/nvidia-uvm /dev/nvidia-uvm
    --dev-bind-try /dev/nvidia-uvm-tools /dev/nvidia-uvm-tools
    --ro-bind /sys/dev /sys/dev
    --ro-bind /sys/devices /sys/devices
    --ro-bind /sys/bus/pci /sys/bus/pci
    --ro-bind-try /sys/class/drm /sys/class/drm
    --ro-bind-try /sys/module/nvidia /sys/module/nvidia

Otherwise I'd get error like:

libEGL warning: failed to open /dev/dri/renderD128: Permission denied
libEGL warning: failed to get driver name for fd -1
libEGL warning: MESA-LOADER: failed to retrieve device information
libEGL warning: pci id for fd 34: 10de:25a0, driver (null)
pci id for fd 35: 10de:25a0, driver (null)
kmsro: driver missing
libEGL warning: egl: failed to create dri2 screen
pci id for fd 35: 10de:25a0, driver (null)

Ah, I see - well, I don't use Nvidia due to their proprietary drivers… so I can't test it, sorry. :)

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Navigation Menu

Repository navigation

Limiting access for tools in a safer way #4667

Question

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Limiting access for tools in a safer way #4667

Description

Question

Activity

github-actions commented on Nov 23, 2025

redtux commented on Dec 3, 2025

tredondo commented on Feb 17, 2026

redtux commented on Feb 18, 2026

tredondo commented on Feb 18, 2026

redtux commented on Feb 18, 2026

github-actions commented on Apr 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions