What exactly the agent did
The action inspector in a development session: kinds of actions and what each shows, statuses, “Raw call and result”, the “Files” tab.
The inspector is the right-hand column of an open session (on a phone — a bottom sheet). It has two tabs: “Action” — the selected action in full, in the form that suits it: terminal, file, diff, code; “Files (N)” — all the files the session read and changed. How to select an action — on the Read a session page.
The action header
- the icon of the kind and the verb with the object — the same as in the feed line: “Read” and a path, “Ran” and a command;
- the line hh:mm · model · turn N s · tool name — when the turn started, which model
answered, how long the turn took and the tool’s technical name (
bash,edit,knowledge_read_entry,jira__get_issue); - the status on the right — see the table below. An action with an error has the error text under its header.
Kinds of actions
The kind is determined by the tool name; it sets the icon, the colour on the session timeline, the verb and how the inspector shows the body of the action.
| Kind | Tools | Verb · object | What the inspector shows |
|---|---|---|---|
| Terminal | bash, shell | Ran · the first line of the command; a background command — Ran in the background | A terminal window: folder, command, output. With a non-zero exit code the output is red. |
| File read | read and tools ending in _read | Read · path | The file with line numbers — exactly the fragment the model got, from the line it read from. A folder listing — as text. |
| File edit | write, edit, multiedit, apply_patch, patch | Wrote (write) or Edited · path | A diff with a caption saying what it was computed against (see below), the +N −N count, below — “Tool result”. |
| Search | glob, grep, search, list, ls and similar | Searched · pattern or query | “Call” — the arguments, “Result” — what was found. |
| Code | execute (Code Mode) | Ran code · the first line of the code | “Model’s code” with line numbers and the “Result” of running it. |
| Knowledge | knowledge_* | Recorded knowledge · title — the developer added the entry; Proposed knowledge — not added — they declined; Proposes knowledge — the request is still awaiting an answer; Looked at knowledge · entry name or query | “Call” and “Result”. This is the organisation’s knowledge base. |
| Handbook | tools with handbook in the name | Searched the handbook · query | “Call” and “Result”. |
| Question to the developer | question | Asked the developer · the first question | The questions with answer options and “Developer’s answer”. |
| Web | webfetch, websearch, fetch | Opened · address or query | “Call” and “Result”. |
| Subtask | task, subagent | Delegated a subtask · description | “Call” and “Result”. |
| Skill | skill | Applied a skill · skill name | “Call” and “Result”. |
| Plan | plan_exit | Proposed a plan · plan title | The plan as text, as the person saw it when approving. |
| To-do list | todo_update | Updated the to-do list · “N of M done” | The list items with done marks. |
| Workflow | workflow_* | Started a workflow, Amended a workflow run, Saved a workflow, Asked the person and others · name | “Call” and “Result”. See Workflows. |
| Automation | automation_* | Proposed an automation · name | “Call” and “Result”. See Automations. |
| Tool | everything else — connection tools, project repositories, your own MCP | the tool name as is | “Call” — the arguments as JSON, “Result” — the answer as JSON or text. |
What the diff is computed against. The record keeps calls, not the file system, so the diff of an edit is built from what the session saw earlier:
- “the replaced fragment” — for
edit: the old text against the new one, as the model passed them; - “against the version written earlier in this session” — for
write, if this file was already written in the session; - “against the version read earlier in this session” — for
write, if the file was read earlier from the first line; - “A new file — or its earlier version isn’t visible in this session” — the session did not read or write it before: the whole text is shown as added. This also happens with an existing file if the model wrote it without reading it.
Statuses
| Status | When |
|---|---|
| awaiting reply | there is no result yet — a live session, or a break after which the answer never came |
| exit code 0 / done | the command ended with zero; for other tools — the answer came without an error |
| exit code N (red) | the command ended with a non-zero code |
| error (red) | the tool answered with an error: JSON with an error field, “Unknown tool”, “Error:” |
The status is taken from the tool’s answer, not from the model’s words: if the model wrote “done” but the command failed, the session timeline and the inspector show an error.
“Raw call and result”
The button under the action body shows two texts unparsed: the call arguments as the model wrote them, and the tool’s answer as it came. This is for cases when the inspector’s view did not show something — a truncated stream, a non-standard answer — or when you need to copy the bytes for analysis.
The “Files” tab
All the files the session read or changed through separate calls, in the order of first access — across the whole loaded session, not one turn. Each has:
- an icon: created, modified or only read;
- a caption: “created”, “modified N times” (for a created one — “created, then modified N times”), “read N times”;
- +N −N — the sum of added and removed lines across all edits of the file in the session.
Clicking a file opens the last action with it on the “Action” tab. Folder listings are not included. If the session did not touch files — “The session did not read or change files through separate calls”.
What isn’t listed here. Edits the model made from Code Mode code (the “Ran code” action) are not recorded as separate calls — you can see them in the code itself and its result. Edits the developer made by hand go nowhere: they did not pass through the model.
Read a session
An open development session: header and metrics, the session timeline with coloured marks, the feed of messages and actions, service calls, “Follow”, phones.
Ask about sessions
Asking the model about development session records: three ways, examples by role, what the model gets, how to read the answer, who sees it, usage and log.