feat(prompt): tell the agent what its sandbox can run
Nightly Build / build (push) Successful in 8m6s

The agent had no way to know its container ships ffmpeg, ripgrep or
tesseract, so it either declined work it could do or spent a round finding
out. This adds a command list to the system prompt as a **discovery hint** —
explicitly not an inventory.

Every decision follows from it being a hint:

- The allowlist (~35 entries, `container/commands.rs`) is the curation; a
  full PATH dump is 800 entries of coreutils noise. The probe exists so the
  list cannot *lie*, not so it can discover: `command -v` at login means we
  never announce something a container recreate threw away.
- The rendered prose says the list is partial and names `command -v`, so a
  tool outside the allowlist costs one check rather than a wrong conclusion.
  An empty probe renders as an explicit "could not be read", never as
  silence under a heading promising a list.
- Order is the allowlist's own, grouped by kind of work — the grouping is
  the curation, and the reader is a model, not a grep.
- Staleness is cheap both ways, so there is no invalidation machinery: a
  login-time snapshot on `UserContext`, non-fatal, refreshed at next login.

The gate is the tool, not the sentinel. Every AGENT.md carries
`common/sandbox.md` — the four system agents included — and the section is
emitted iff the turn's model is shown `execute_cmd`, derived from
`allow_tools` plus the security group's visibility filter for a root turn
and from `child_defs` for a sub-agent: always the same definitions the model
will see. `has_execute_cmd` therefore joins the PrefixCache key, since the
group is switchable mid-conversation and that switch already rewrites the
tool payload in the same provider cache.

The fragment holds only the heading and one stable sentence; every
conditional claim lives in the renderer, because prose promising
`sudo apt-get install` is not the renderer's to retract when the tool is
absent. `execute_cmd`'s own description loses `(python + node available)`:
its job is steering away from the shell, and a capability advertisement
diluted it.
This commit is contained in:
Daniele
2026-08-09 09:49:50 +01:00
parent c27da4e6ab
commit 5765941758
31 changed files with 459 additions and 38 deletions
+27
View File
@@ -0,0 +1,27 @@
# Your sandbox
Every member of this instance has their **own private Linux container**, and you work inside theirs. It is where `execute_cmd` runs, and it is separate from everyone else's: nothing you do in one person's sandbox is visible from another's.
## What is in it
Mounted into it are the places you already know by name: the home directory (`~`), the shared folders that person belongs to, their projects, and the read-only `skills/` and `docs/` trees. Everything else in the container — `/tmp`, `/etc`, an installed package's files — belongs to the sandbox alone.
The distinction matters for one reason: **the mounted directories survive, the rest does not.** A container can be rebuilt at any time (a software update, a change to someone's folder access), and when it is, it comes back from a clean image. Files under `~`, the shared folders and the projects are untouched. Anything installed into the container is gone.
## What you can run
Your prompt lists **some** of the commands the sandbox provides — the common ones, checked at the start of the session so the list never claims something that is not there. It is a shortcut, not an inventory: the sandbox has far more than the list shows, and a command missing from it may well be installed. Check any specific one with `command -v <name>`.
You are free to work in there as you see fit, including installing what you need:
```
sudo apt-get install -y <package>
```
No password is needed. Because an install is lost when the container is rebuilt, prefer installing quietly as part of doing the work over telling the user to install something — and if a task depends on a heavy tool being present every time, say so, so an admin can have it added to the base image.
If a user asks what the assistant can *do* with files, media or documents, the honest answer is grounded here: a full Linux environment with the usual toolbelt, in which you can also install what is missing.
## When you cannot run commands
`execute_cmd` is not always available. A restrictive security group can withhold it, and some background agents are given no tools at all by design. When that happens your prompt says so plainly instead of listing commands — take it at face value and do the work with the tools you do have, or explain what you would need.