Chapter 4 of 15

Reading What the Agent Did

The agent has changed something in the export. Freddy's old reflex is to scroll. This chapter is about the three things the window does so that he does not have to: it shows the work as it happens, it stops and asks when a decision is his, and it can put every file back to how it was before a message.

The problem

An agent produces a lot of text and a few facts that matter. The facts — which file it edited, which command it ran, what it needs from you — are scattered through the text, and the one that matters most (it is waiting) has no sound. Worse, when it goes wrong, the question is not what it did but how to get back.

The hard way

Without a view of the work, you review by git diff after the fact, and you recover by git checkout, which only works for files Git already knows about and only if you had committed what you wanted to keep. Anything between your last commit and the agent's mistake is a loss you cannot fully describe.

What the agent shows

  • Text streams in as Markdown. Its reasoning is shown in collapsible blocks when the agent shares it.
  • Tool calls appear as rows: a command, a file read, a search, and so on. Click one to see its input and output. Edits show a diff of the change, and new files show their content. Running commands show their output live.
  • Task lists the agent keeps appear as a card with progress. The latest one is shown in full.
  • Subagents: work the agent hands to a subagent is grouped under one card with its own tool calls.
  • After every turn, a line shows how long it took and what it cost.

The one-line rows keep a long turn readable. A turn that read nine files and edited two is eleven short rows, not a wall of text, and you open only the two edits.

Approvals and questions

When the agent needs permission, an approval card shows what it wants to do:

  • Allow: this time.
  • Allow for session: this kind of action for the rest of the session.
  • Deny.

The thread is marked needs approval in the sidebar, and you get a notification if you are elsewhere. That is the answer to chapter 1's silent question.

When the agent asks a question, it appears as a form. Pick an option, or several if the question allows it, or type your own answer under Other. Then press Submit, or Dismiss to not answer. Yes/no questions get Yes and No buttons.

Allow for session is a bigger yes than it looks. It covers this kind of action for the rest of the session, not only the one on the card. That is convenient for a test command you will run twelve times, and worth a second thought for anything that deletes. Use Allow when you are not sure.

Plans

In Plan only mode, Claude Code presents its plan as a card with three answers:

  • Approve, accept edits: carry out the plan; edits do not need approval.
  • Approve, ask for edits: carry out the plan, asking before each edit.
  • Keep planning: stay in plan mode and keep refining.

Freddy's pattern, and a good default: ask for the plan first, read it, and approve it as ask for edits the first time a kind of task comes up. Once the plan has been right a few times, accept edits stops being a leap.

Message actions

Hover over a message to see its actions:

  • Copy the text.
  • Edit and resend (your messages): puts the text back in the message box.
  • Restore files to before this message (your messages): puts every file in the thread's folder back to how it was before that message was sent. Edits made since are undone, and files created since are deleted. The conversation and Git commits are not changed. Workspace asks you to confirm first.
  • Pin: keeps the message in the Context tab (chapter 8).

Long messages are folded; click Show more to expand them. ⌘F in the message box opens a search bar for the conversation: it shows the number of matches and jumps between them (Enter for the next, Shift+Enter for the previous, Escape closes it).

Checkpoints: why going back works

Restore is not magic and it is not git stash. Before every turn, Workspace saves a snapshot of the thread's folder, as long as it is a Git repository. The snapshot is stored as a hidden Git reference and does not touch your branch, index or stash. Snapshots make Restore files possible and let the Changes tab show what one turn changed (chapter 5). Deleting a thread deletes its snapshots.

Two limits, because they are the ones that surprise people:

  • It is for files. The conversation and your Git commits are not changed by a restore. If the agent committed something, the commit is still there.
  • It needs a Git repository. No repository, no snapshot.

If you use Elyra Grove to run the project as an app, the checkpoint also takes a snapshot of the app's database (a copy of a SQLite file, or a grove db snapshot of MySQL, PostgreSQL or ElyraSQL, found from the app's .env). Restore files then puts the database back too, so data and migrations the agent changed are undone with the code. The latest 10 database snapshots per thread are kept; turn this off in Settings → Agents & MCP → Database in checkpoints.

Try it: in a throwaway thread, ask the agent to create a file and change another. Hover over your message and choose Restore files to before this message. Watch the new file disappear and the other come back. Then do it once more, deliberately, on a task you care about, so the first time you need it is not the first time you use it.

What you learned

  • What the window shows as it happens: tool rows, diffs, task lists and costs
  • The three answers on an approval card, and why Allow for session is a bigger yes
  • How plan cards work and a safe pattern for approving them
  • How to restore files to before a message, and what the restore does not undo
  • How checkpoints are stored, and the two limits: files only, and a Git repository
Next: in Chapter 5 you review the changes properly: the Changes tab, scopes, committing, and pull requests.