feat(prompt): tell the agent what its sandbox can run
Nightly Build / build (push) Successful in 8m6s
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:
@@ -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.
|
||||
Reference in New Issue
Block a user