READING A TRACE
What the labels
on a tool call mean.
Every row in Tool calls carries two labels. The Tool column says what kind of step it was. The Sandbox column says what independent evidence there is that it happened.
They answer different questions and are decided in different ways. A category is a description of the step. A sandbox label is a comparison of recorded facts, and nothing else.
Tool categories
The Tool column shows the category first and the tool’s real name beside it, such as Run · Bash or Edit · apply_patch. A category is named for what the call did, not for the tool or agent that made it, so Claude Code’s Read and a Codex cat are both Read.
| Category | What it means | Examples |
|---|---|---|
| Read | Looked at the contents of a file. | Read, cat, head, sed -n |
| Search | Looked for files or text, or listed what is there. | Grep, Glob, rg, find, ls |
| Write | Created or replaced a whole file or folder. | Write, echo … > file, cp, mkdir |
| Edit | Changed part of an existing file, or its permissions. | Edit, apply_patch, sed -i, chmod |
| Delete / move | Removed, renamed or moved files. | rm, mv, a patch that deletes a file |
| Run | Executed a script or program. | sh check.sh, python tool.py, node server.js |
| Test | Ran tests, a linter or a type check. | pytest, npm test, tsc, eslint |
| Build / install | Built the project or fetched its dependencies. | npm install, pip install, make, cargo build |
| Git | Version control. | git status, git commit, gh pr create |
| Web | Reached the network. | WebFetch, WebSearch, curl, wget |
| Plan | Organised its own work, or asked you something. | TodoWrite, update_plan, AskUserQuestion |
| Delegate | Handed work to another agent or an outside tool. | Task, Skill, any MCP tool |
| Not sure | RayTrace could not tell what kind of step this was. | An unfamiliar program, or a tool RayTrace does not know |
How a category is decided
- A named tool is placed by its name.
- A shell command is placed by the programs it runs. RayTrace reads the command line, skips set-up such as
cdandexport, and looks each program up. - A command with several parts takes its most consequential one, in this order: Delete / move, Edit, Write, Git, Build / install, Test, Web, Run, Search, Read. So
cd app && cat notes.txt && rm old.txtis Delete / move. - A command RayTrace does not recognise is put to a decision model, which chooses among the same categories from the command’s text. When it is not confident, or is not available, the step reads Not sure.
A script is Run, whatever it does inside: sh check.sh is Run even if the script deletes files. The category describes the step the agent took. What the script then started is in Sandbox evidence.
Sandbox labels
The Sandbox column compares what the agent reported with what RayTrace recorded independently. A command is confirmed by the process the sandbox saw. A file write is confirmed by a snapshot of the project folder taken after the call. No model has a say in any of these labels.
| Label | What it means | How it is decided | What to do |
|---|---|---|---|
| ✓ ran | The sandbox saw this command run. | A process the sandbox recorded was matched to the tool call: by the call’s own id where the agent passes one, otherwise by the command’s text inside the call’s time window. | Click the label to open that process in Sandbox evidence. |
| ⚠ ran, differs | The command ran, but the agent was told something different from what the sandbox saw. | The exit code in the agent’s result does not match the one the sandbox recorded, or the run time it reported is far from the observed one. | Click the label and compare. The sandbox’s record is the independent one. |
| ✗ rejected | The agent’s own sandbox policy refused to run the command. | The result the agent got back says the command was refused. | Nothing ran. Look at what the agent did next. |
| — not seen | A command was proposed, and the sandbox has no process for it. | No recorded process matched this tool call. | Missing evidence is not proof that it did not run. Open Sandbox evidence and look at what ran around that time. |
| ✓ file changed | The agent reported a write, and the file is different on disk. | The snapshot of the project folder taken after the call lists the file as added, edited or deleted. | Click the label to see the files that changed. |
| ✗ no change | The agent reported a successful write, but the file on disk did not change. | The file is inside the project folder and no snapshot from that round trip lists it. | Worth a look. It is also what you see when a file is rewritten with exactly the content it already had. |
| in agent | A built-in tool that starts no program and changes no file: a read, a search, a plan. | The tool is one RayTrace knows to run inside the agent itself. | There is nothing for the sandbox to observe. You have the agent’s report only. |
| not covered | RayTrace was not watching there. | A write outside the project folder (/workspace), a file too big to snapshot (over 5 MB), a write no snapshot was taken for, or a run that was not in a sandbox. | Treat it as the agent’s word. This is different from “not seen”, where RayTrace looked and found nothing. |
What counts as proof
- The sandbox’s own observation: ✓ ran, ⚠ ran, differs, ✓ file changed and ✗ no change. These come from a process the sandbox recorded or from the files on disk, not from anything the agent said.
- The agent’s report only: ✗ rejected and in agent. RayTrace shows what the agent was told, and has nothing of its own to set beside it.
- No evidence either way: — not seen and not covered. Neither one says the step did not happen.
The sandbox records programs starting and exiting, and snapshots the project folder after each call that can change files. It does not record which files a program read, so a read made by a built-in tool is always “in agent��.