Running Claude Code in the terminal without losing track of the files it changes

A terminal session with Claude Code is fast to start and easy to leave running. The difficulty shows up later. After twenty minutes and a dozen prompts, the scrollback holds a long account of tool calls, and the question "which files did it actually change" has no single place to look. Some edits went through its file editing tool. Some happened inside shell commands it ran. A formatter may have touched files nobody asked about. The conversation describes all of this, but the conversation is not the file system.

This guide is about keeping that picture accurate while working in the terminal on a Mac. It covers where the reliable record of changes lives, what the built-in rewind can and cannot restore, how to keep parallel work separate, and the few terminal settings that stop a long session from running unnoticed. Details come from the Claude Code documentation at code.claude.com as of September 2026.

The conversation is not the record

Claude Code reports what it does as it goes: a line for each file read, each edit applied, each command run. It is tempting to treat that stream as the list of changes. It is incomplete in a specific way.

Edits made with Claude's file editing tools are reported clearly, one file at a time. Changes made by shell commands are reported only as the command. A line such as Bash (npx prettier --write src) followed by "12 files changed" says that twelve files moved, not which twelve. A mv or rm inside a longer command, a code generator, a package install that rewrites a lockfile, a build step that writes into a checked-in folder: all of these change files without naming them in the conversation.

The reliable record is the file system itself, and in a Git repository the fastest way to read it is Git. Running git status in a second terminal tab, or asking the session what files have changed?, lists every modified, added and deleted file regardless of how it changed. git diff --stat gives the size of each change. For files outside version control, sorting a folder by modification time, with ls -lt in the terminal or the date column in a file window, shows what was touched most recently.

This leads to the single most useful habit in terminal work: commit, or at least stage, before handing over a task. A clean starting point makes the end of the task legible. Everything in git status afterwards belongs to the task, and nothing from earlier work is mixed in.

What rewind restores, and what it does not

Claude Code creates a checkpoint before each prompt that starts a turn. Typing /rewind, or pressing Esc twice with an empty prompt, opens a menu listing each prompt in the session. Selecting one offers to restore the code, the conversation, or both, to the state before that prompt. Checkpoints are saved with the conversation, so rewind still works after resuming a session with claude -c or claude -r. File snapshots are kept for the most recent 100 checkpoints in a session and cleaned up by default about 30 days after the session last saved one.

The limits matter more than the feature. The documentation lists them plainly:

Change	Restored by rewind?
Edits made with Claude's file editing tools	Yes
Files changed by shell commands (rm, mv, cp, formatters, generators)	No
Edits by most subagents, including background forked skills	No, use Git
Edits typed by hand in an editor during the session	No
Edits from another session running at the same time	No, unless they touched the same files
Symlinked or hard linked files	Skipped with a warning

Read against the previous section, the pattern is clear. Rewind covers exactly the changes that the conversation already reports well, and misses exactly the ones that are hard to see. It is a quick undo for the last few edits, and the documentation says as much: checkpoints are not a replacement for version control.

In practice, rewind is best for steering. When an attempt goes the wrong way, restoring both code and conversation removes the failed approach from the session's context and puts the original prompt back in the input to be rephrased. For undoing a whole task, git restore or git stash on a clean starting point is complete in a way rewind is not.

The symlink limit deserves a note for Mac users who manage dotfiles. Configuration files linked into a project by a dotfile manager, and packages hard linked into place by pnpm, fall into this category. A restore will report "Restored the code, but skipped N files" and leave those files as they are.

Folders that are not in Git

Not every folder Claude Code works in is a repository. Research notes, a set of exported spreadsheets, a folder of images being renamed, a document archive being sorted: these are common uses, and they have no git status to fall back on. Rewind still covers edits made with the file editing tools, but a task that moves or renames files usually does so with shell commands, which rewind does not track.

There are two practical options. The first is to run git init in the folder before the task, commit its current state, and treat it as a repository for the duration. Git handles binary files such as images and PDFs well enough to record that they were added, removed or renamed, and the history can be deleted afterwards if it is not wanted. The second is to copy the folder before starting, so there is a plain snapshot to compare against or restore from.

It also helps to ask for a plan before any bulk operation on files. In plan mode the session describes what it intends to move or rename without doing it, and the list can be checked against the folder first. For renames, asking it to write the mapping of old names to new names into a text file before applying it leaves a record that outlives the conversation.

Keeping parallel work separate

Running two terminal sessions on the same repository is common and usually fine for reading. For writing, it is the fastest way to lose track of changes, because both sessions edit the same working tree and each one's git status shows the other's work.

The command line's --worktree flag solves this by giving a session its own Git worktree: a separate checkout of the repository on its own branch. Changes in one session do not appear in the other until they are committed and merged. The desktop app offers the same thing as a worktree option when a session starts, and stores worktrees under .claude/worktrees/ in the project by default.

When worktrees are not an option, a simpler rule helps. Give each session a different part of the repository and say so in the first prompt: "only edit files under docs/". The instruction is guidance rather than enforcement, so check git status before committing either session's work.

For tasks that span two repositories, starting in one and adding the other with --add-dir keeps both in one session with one record, which is easier to follow than two sessions each seeing half the change.

Terminal settings that keep a long session visible

Losing track of changes often starts with losing track of the session. It finished twenty minutes ago, or it has been waiting on a permission prompt, and nobody noticed. A few settings from the documentation's terminal configuration page address this directly.

Notifications. When Claude finishes a task or pauses for permission and the terminal appears to be unattended, it fires a notification event. By default a desktop notification is sent only in Ghostty, Kitty and iTerm2. In iTerm2, forwarding has to be enabled under Settings, Profiles, Terminal, by checking Notification Center Alerts and enabling "Send escape sequence-generated alerts" under Filter Alerts. In Apple Terminal and other terminals, setting preferredNotifChannel to "terminal_bell" in the settings file rings the bell instead. A Notification hook can also play a sound, for example with afplay and a system sound.

Multiline prompts. Enter sends the message. Shift+Enter inserts a newline without setup in Ghostty, Kitty, iTerm2, WezTerm, Warp and Apple Terminal. In the VS Code, Cursor and Zed terminals, running /terminal-setup once adds the binding. Ctrl+J, or a backslash followed by Enter, works everywhere.

Option key shortcuts. Some shortcuts use Option, such as Option+P to switch models. Most Mac terminals do not send Option as a modifier by default. In Apple Terminal the setting is "Use Option as Meta Key" under Settings, Profiles, Keyboard; in iTerm2 it is setting the Option keys to "Esc+". Accepting the first run terminal setup prompt in Apple Terminal does this automatically.

tmux. Inside tmux, notifications and Shift+Enter need three lines in ~/.tmux.conf: set -g allow-passthrough on, set -s extended-keys on, and set -as terminal-features 'xterm*:extkeys'.

A routine for a terminal session

Put together, a session that stays legible from start to finish has a simple shape.

1. Clean start. In the project root, git status shows nothing pending. If something is, commit or stash it.
2. One task per prompt chain. State the task and its boundary: which files or folders it may touch, and how the result will be checked.
3. Second tab for the record. Keep a second terminal tab in the same folder for git status and git diff. Checking it after each step costs seconds.
4. Watch for shell side effects. When the session runs a formatter, a generator or an install, check what it changed before moving on. These are the changes rewind will not undo.
5. Review the whole diff at the end. Look for files that were not part of the task, deleted or weakened tests, and changed lockfiles.
6. Commit or discard. Commit with a message that describes the change, or restore the working tree. Either way the next task starts clean.

The second tab in step three is where most of the friction lives. It means switching between the session, the Git view and, for anything that is not code, a Finder window to see what the files look like. A file manager with a built-in terminal puts the session and the folder in one window, which makes steps three and four a glance rather than a switch. The features page shows that layout, and the comparison with other file managers lists which tools offer an embedded terminal.

When the terminal is not the best place

The terminal is the most complete surface for Claude Code: it is the only one with non-interactive runs, every permission mode and every provider. It is not the best place to review. For large changes across many files, the desktop app's diff view, where individual lines can be commented on and Claude revises from the comments, is easier to read than a long git diff. The two share configuration and can run on the same project, and /desktop moves a terminal session into the desktop app on a Mac signed in with a subscription.

A reasonable split is to run and steer in the terminal and switch to a visual diff when a change is too large to read comfortably in scrollback.

What to change first

Start every task from a clean git status and keep a second tab open to check it after each step. Turn on notifications for the terminal in use, so a finished or waiting session is never missed. If switching between the terminal and the folder is where changes slip by, Atriens keeps both in one window on the Mac.