Using AI Coding Agents in the Terminal

A terminal AI coding agent is a program you start inside a project directory so it can help with that project. You will learn to start an agent in the right project, supervise its commands, and review its changes.

Before continuing, learn the basic navigation and command patterns in The Terminal: A Practical Guide and the Git basics in the official Git Documentation.

Only a little Git is needed at this stage: recognize what a repository is, and read git status and git diff output, because agents show their proposed changes that way. Deeper Git knowledge can wait.

Treat the agent like a contractor working inside your house. You choose which house it enters, explain the job, decide which rooms it may enter, and inspect the work before accepting it. A skilled contractor can still misunderstand a request or open the wrong door, so access and review remain your responsibility.

What a Terminal Coding Agent Is

A terminal coding agent combines a conversation with access to development tools. You start it from a shell, describe a task in ordinary language, and let it inspect the project files needed to understand the request. It can then propose file edits and shell commands, while its permission settings determine when it asks for approval.

Widely used agents include Claude Code from Anthropic, Codex CLI from OpenAI, and opencode as an open source project. Their interfaces differ, but the beginner workflow stays recognizable: enter the project, start one agent, describe one focused task, and review what it proposes.

> Explain where this project renders its weather forecast.
> Do not edit any files yet.

The > symbols mark text typed into the agent's chat, not shell redirection, so do not type them. This opening request gives the agent a narrow investigation and an explicit read-only boundary. It also gives you a chance to check whether the response names files that actually belong to the project.

Start an Agent in the Right Project

The working directory is the location from which a terminal program begins. A coding agent uses that location as the starting point for discovering project files, instructions, and version-control information. Starting one directory too high may expose unrelated projects, while starting inside a small subdirectory may hide files the task needs.

Check the location and contents before launching the installed agent. The following example enters one project, prints its path, and lists its top-level files. Read the output and confirm it is the right project before starting the agent:

cd "$HOME/projects/weather-dashboard" && pwd && ls

The && operators stop the chain if cd fails, so pwd and ls do not run from the wrong location. The pause before launch lets you read the printed directory and file list.

Before continuing, install Codex CLI from OpenAI's official installation instructions.

After confirming the output, start Codex CLI:

codex

If Claude Code is the agent you want to try, install it from the official install page, then run claude.

For opencode, follow its official installation instructions before running opencode.

After installing any of these tools, typing codex, claude, or opencode at the prompt starts it; use the matching --version command, such as codex --version, to confirm the installation without starting a session.

Supervise an Agent Session

Give the agent a small task with a visible finish line. "Add an empty message to the weather card when no forecast is available" is easier to review than "improve the dashboard." Name any limits that matter, such as the file to change, the behavior to preserve, or the checks to run.

Before the first session, check the official documentation for Claude Code, Codex CLI, or opencode, then configure its approval or permission settings. Keep confirmations enabled wherever the tool offers them.

When the agent proposes a command, read the command itself before approving it. Check the program name, every option, and each path.

A test command aimed at the current project is different from a removal command aimed at a parent directory. If part of the command is unfamiliar, ask the agent to explain it or decline it and inspect the relevant documentation.

Use this quick comparison while reviewing a proposed command:

Safer Signal	Risky Signal
Known project path	Parent or home path
Read-only command	Delete or overwrite
Explained options	Unfamiliar options

After the agent reports that the task is complete, review the working tree with Git:

git status --short
#  M src/components/WeatherCard.tsx
# ?? src/components/WeatherEmptyState.tsx

git diff HEAD
# Example diff output:
# -  return null;
# +  return <p>Forecast unavailable.</p>;

The git status --short command lists tracked changes and marks new files with ??. git diff HEAD shows the removed and added lines in tracked files; HEAD makes the diff include staged changes too. New files are not in that diff, so open them directly before accepting the work.

If the agent changed an unrelated configuration file, ask why before continuing. If the explanation does not match the task, ask the agent to undo that specific change, then re-review the diff. One focused request followed by one diff review keeps the inspection small enough to do properly.

Repeat the review after any correction or test failure. The agent's summary is a useful index, but the files and command output are the evidence. Your inspection is the contractor's final room-by-room check before the job is accepted.

Set Boundaries Before Work Begins

Start agents only in directories that contain the intended project. A home directory, desktop, or broad projects folder can include personal documents, credentials, backups, and unrelated repositories. The agent does not need access to those rooms for a focused coding task.

Version control supplies checkpoints, a readable record of changes, and an undo path for committed work. Begin from a state you understand, check git status before the session, and review git diff before committing. Uncommitted work from another task makes it harder to separate the agent's edits from changes that were already present.

Review commands especially carefully when they install software, remove files, change permissions, contact external services, or operate outside the project directory.

• Open the smallest directory that contains the complete project.
• Describe one focused task and its boundaries.
• Read proposed commands before granting approval.
• Inspect changed files and run relevant checks.
• Commit only changes you can explain.

These boundaries do not assume the agent will make a mistake. They make any mistake smaller, visible, and easier to reverse.

Common Pitfalls & Debugging

The Agent Started in the Wrong Directory

Symptom: the agent discusses unrelated files or cannot find the expected project. Cause: it was launched from a parent, sibling, or nested directory. Fix: stop the session, run pwd and ls, enter the correct project with cd, then launch a new session there.

A Command Was Approved Without Being Read

Symptom: a command changes more than the task required or targets an unexpected path. Cause: approval was given from the description instead of the complete command. Fix: stop further work and ask the agent to undo that specific change. Re-review the diff. Use version control or a backup if the agent cannot undo it safely.

The Changes Are Hard to Explain

Symptom: the result appears to work, but you cannot explain several changed lines. Cause: the task was too broad or the review relied on the agent's summary. Fix: run git diff before continuing, ask about each unexpected change, and reduce the next request to one behavior or file.

The Agent Command Is Not Found

Symptom: the shell reports claude: command not found, codex: command not found, or opencode: command not found. Cause: the agent is not installed, the command name is misspelled, or its installation directory is missing from PATH. Fix: check the official installation guide and reopen the terminal if the installer changed your shell path.

The Agent Appears Stuck

Symptom: the terminal stops responding to ordinary input while the agent or one of its commands runs. Cause: a foreground process is still active, waiting, or taking longer than expected. Fix: read the latest output, then press Ctrl+C to interrupt the foreground process in the usual case.

Conclusion

A terminal coding agent is safest when you choose the right project, give it a narrow task, and inspect its commands and file changes. Keep the contractor inside the intended rooms, then accept the work only when you can explain the diff.

Frequently Asked Questions

Do you need to know how to code to use a terminal agent?

You can ask an agent to explain an unfamiliar project without knowing much code, but basic programming knowledge helps you judge its edits and spot incorrect assumptions. Start with small, reversible tasks and read every change instead of treating the agent's answer as proof.

Which terminal agent should you start with?

If your team already uses one, use that, because shared conventions matter more than any feature difference. Working alone, check what you are already paying for first. Running any of these costs something in model usage, but how you pay differs: some are tied to a vendor subscription, while opencode is open source and runs against whichever provider key or local model you point it at. An assistant plan you already hold is usually the cheapest way in.

If none of that applies, the choice matters less than it looks. Claude Code, Codex CLI, and opencode all launch from a project directory with their own terminal command, so every habit on this page transfers: check where you started it, supervise the commands, review the diff. Pick one, learn the shape, and switch later if you need to. For a direct feature comparison, see Claude Code vs Codex and Claude Code vs opencode.

Can a terminal agent break your system?

A terminal agent can break your system by running a harmful command or editing the wrong file when it has sufficient access. Limit the working directory, keep important work in version control, read proposed commands, and avoid confirmation-skipping modes until you understand their permissions.

Do terminal agents work on Windows?

Terminal agents work on Windows, although installation and shell behavior depend on the tool. Windows Subsystem for Linux (WSL) provides a Linux terminal where common Bash commands, project paths, and agent workflows closely match the macOS and Linux examples on this page.

Can a terminal agent read files outside the project you started it in?

It depends on the tool and the permissions you grant, and several can. The working directory is the default scope rather than a hard boundary, which is why starting the agent in the right project, and not in your home directory, matters.

What does an agent's auto-approve mode actually turn off?

Less than the name suggests, and the answer differs by tool. There is no shared permission model across terminal agents, so check your own tool's documentation rather than assuming the behaviour carries across.

Most of them keep two separate controls: what the agent is allowed to touch, and whether it asks before each step. Turning off the asking does not widen the first. Codex CLI selects a sandbox policy with --sandbox independently of its approval setting, and reserves a separate --dangerously-bypass-approvals-and-sandbox flag for dropping both at once. Claude Code likewise separates --permission-mode and its per-tool allow and deny lists from the --dangerously-skip-permissions escape hatch.

The useful question is not whether auto-approve is on. It is which boundary still holds while it is. Confirm that before running an agent anywhere you cannot afford to lose, and stay in a scratch checkout while you are still learning a tool's defaults.

How is a terminal agent different from AI autocomplete in an editor?

Autocomplete suggests the next lines while you type and you accept or reject each one. A terminal agent takes a goal, then reads files, edits several, and runs commands on its own. One assists your typing; the other acts.

Self-Check

1. Which pair checks the current project before an agent starts: (A) pwd and ls, (B) cp and mv, or (C) grep and sort?
2. Why does the location-check command place && between cd, pwd, and ls?
3. Predict the output: the agent edits one tracked file named src/app.ts without staging it. What does git status --short print?
4. What should you do when a proposed command contains an unfamiliar option or path?
5. What should you check before the first session when a tool offers approval or permission settings?

Answers

1. A: pwd and ls. They show the current directory and its contents before the agent receives project access.
2. Each command runs only after the previous one succeeds. A failed directory change stops the remaining location checks.
3.  M src/app.ts. The M in the second status column marks a tracked file with unstaged changes.
4. Decline or pause the command and ask for an explanation. Approve it only after its program, options, and targets are clear.
5. Check the tool's official documentation and configure the settings. Keep confirmations enabled wherever the tool provides them.

Related DevOps Guides

• Learn the prerequisite commands in The Terminal: A Practical Guide.
• Look up command syntax and expected output in Terminal Commands: A Practical Reference.
• Return to the DevOps and server administration hub for the cluster overview.
• Use server statistics and observability to understand the systems an agent may inspect.
• Build recovery habits with server contingency planning.