Inside the terminal agent there is its own set of commands - for modes, sessions, output, external servers, plugins, configuration, the sandbox, sign-in and diagnostics. The catalog grows with versions and installed skills, so the book separates two things: the static reference and the live list. The first is useful as a map, the second as the source of truth for your build, and it opens right there in the conversation.
A separate mechanism is the shell mode that runs a command straight from the conversation. It has features worth knowing before first use, otherwise they look like breakage. Every command runs independently, so moving to another directory does not persist between calls. Execution time is limited, and interactive prompts and endless output streams are not supported.
Those limits are not accidental - they define the tool's purpose. Shell mode exists for short proofs: check the status, run a focused test, verify the build. A development server, a migration, an interactive installer and an endless log live in an ordinary terminal with their own lifecycle. Trying to run them in a short-command mode ends in a timeout, and that is correct behavior rather than an error.
It helps to see how this looks in practice once. Below are a status check, running tests in a subdirectory in one line, and viewing the changes. Note the second line: since the directory does not persist between calls, the move and the command are combined into one call.
The reason for that is simple, and once you know it you stop stumbling. Every call goes into its own login shell and dies together with the command. It is not only the directory that fails to persist: exported variables, an activated language environment, a selected tool version - all of that lives for exactly one call. So everything a command needs is written in the command itself rather than relying on state left over from the previous one.
A quick review of changes is invoked by a separate shortcut and is arranged like a reader: arrows switch files and scroll, a separate key adds a follow-up, and for long output there is its own viewing mode. That is exactly what the terminal lacks compared with the editor - the ability to walk the changes file by file without leaving the conversation and without assembling context again.
The time limit is thirty seconds, and it is not a detail but a boundary of applicability. A status check and a focused test fit; a full monorepo run or a dependency install does not. The sign that you have hit exactly this limit is recognizable: the command breaks off without a meaningful error, always at roughly the same place. The cure is not a retry but narrowing the run or moving it to an ordinary terminal.
There is an important subtlety about permissions. Commands with output redirection cannot be allowed right in the call line - their behavior is described by an exact policy in the configuration. That is not pedantry: redirection changes where the result goes and therefore belongs to permissions rather than to command syntax. The right place for such decisions is the configuration file, where they are visible and can be reviewed.
The engineering conclusion is simple: the terminal agent is convenient exactly where work fits into short verifiable steps. It does not replace the ordinary terminal and should not: long-running processes have their own lifecycle, their own logging and their own way of being stopped, and pulling them into a conversation makes both the conversation and the process worse.
The typical failures are predictable. Expecting a directory change to persist between calls. Running a development server in short-command mode and blaming the timeout on a bug. Trying to allow a command with redirection right in the call. And treating the static command list as complete without looking at the live catalog of your version.
/shell git status --short
/shell cd packages/web && pnpm test -- --runInBand
# the directory does not persist between calls - combine the move and the command in one call