Can the claw-wrap daemon be run in firejail too

[dan-greff]

I'm thinking about how to limit what files a command can see.

[dedene]

Thanks for the question, and sorry for the delay. I completely missed your question here 🤦‍♂️

Short answer: not the daemon itself, but sandboxing the spawned tools again could be a very good feature idea.

The daemon needs access to credential stores like pass or gpg, macOS keychain, 1Password, etc. to fetch secrets. Fully sandboxing it would defeat its purpose. However, the tools it spawns, like gh, do not need that access. They only receive credentials via environment variables.

Right now, spawned tools inherit the daemon user’s full filesystem view. There are two ways this could be addressed:

1. Per tool exec prefix, feature request

Something like:

tools:
  gh:
    binary: /home/linuxbrew/.linuxbrew/bin/gh
    exec_prefix: ["firejail", "--profile=/etc/firejail/gh-tool.profile"]

The daemon would prepend this to the command, so gh repo list becomes:

firejail --profile=/etc/firejail/gh-tool.profile -- gh repo list

Each tool could have its own sandbox profile limiting filesystem access.

2. Run the daemon user with minimal permissions

Run the daemon as a dedicated user, for example claw-wrap, that only has access to the credential store and tool binaries, and no access to the agent’s workspace, home directory, etc. The systemd service already supports User= for this.