Agentic coding in practice: Codex, Claude Code, and Copilot CLI with pull requests and tests

Agentic coding is not just asking a model to suggest a function. The agent reads a repository, chooses tools, edits several files, runs commands, and presents a change that another person or a CI system must still trust. The useful comparison is therefore the whole control loop: how a tool starts, learns repository rules, gets access, verifies behavior, shows a diff, and reaches a pull request.

This article compares the terminal workflows documented for OpenAI Codex CLI, Anthropic Claude Code, and GitHub Copilot CLI. The documentation snapshot is 28 August 2026. It is not a personal benchmark, speed test, or report of hands-on runs. Commands are representative examples from the products’ documentation and need to be adapted to a repository’s scripts and policies. “Verified” means that the vendor documents the capability. “Practical implication” is an operating recommendation inferred from those documented controls.

The same task, viewed through three control planes

Use one bounded task to compare agents: “Add validation for an expired session, update the unit tests, run the relevant checks, show the diff, and prepare a pull request without pushing to the default branch.” The task has a clear boundary, an observable test command, and a reviewable artifact. It also exposes where each product expects a human to make decisions.

Control plane	Codex CLI	Claude Code	GitHub Copilot CLI
Local entry point	`codex` or `codex exec`	`claude`	`copilot` or `copilot -p`
Repository guidance	Layered `AGENTS.md`	`CLAUDE.md`, importable `AGENTS.md`	Copilot instructions, path rules, `AGENTS.md`
Permission model	Sandbox plus approval policy	Allow, ask, deny, and modes	Tool, path, URL, and sandbox scopes
Test loop	Run the repository command	Find, write, run, and fix tests	Agent commands or post-change hooks
Review	`/review`, no tree changes	Git review and Actions automation	`/review` and review agent
Pull-request path	Action review; Git tools for local PRs	Git PRs and `@claude` in Actions	`/pr`, CI fixes, and cloud delegation
Non-interactive work	`codex exec` with sandbox flags	`claude -p` and Actions	`-p`, autopilot, Actions

This is a capability map, not a scorecard. Fit depends on repository hosting, credentials, and the required level of approval.

Setup and the first safe run

Codex documents installing the standalone CLI, opening a project directory, and signing in on first use. Start in a Git repository, ask for a summary, and inspect permissions with /status and /permissions. For automation, use codex exec.

Claude Code documents native installation for macOS, Linux, WSL, and Windows PowerShell, followed by claude in the project directory and first-use authentication. Homebrew and WinGet are also documented. Treat the first run as a trust decision because the CLI can read, run commands, and modify files.

Install Copilot CLI through a supported package or platform channel, then start copilot. The first session asks whether the folder is trusted. GitHub warns that the CLI may read, modify, and execute files below it. Authenticate with /login, and do not remember a directory unless its scripts are understood.

For all three, use a disposable branch or worktree, record a baseline test, inspect loaded instructions, allow only needed commands, and protect the default branch. This is a process recommendation, not an automatic product guarantee.

Repository instructions are part of the interface

Codex reads AGENTS.md before work. Its chain includes a global file and one file per directory from project root to the current directory. AGENTS.override.md wins within a directory, while specific files follow broader guidance. Put test commands and security rules at the root, with service conventions in nested files.

Claude Code reads CLAUDE.md and CLAUDE.local.md in the directory hierarchy. It does not read AGENTS.md directly, but CLAUDE.md can import it with @AGENTS.md. Keep shared build, test, and architecture rules in CLAUDE.md, personal preferences in the ignored local file, and path rules in .claude/rules/.

Copilot CLI supports .github/copilot-instructions.md, path-specific .instructions.md files, and AGENTS.md. copilot init can initialize guidance. These files shape prompts, not permissions. “Never touch production credentials” still needs denied paths, environment controls, and CI policy.

Keep one short AGENTS.md, add a Claude import, and add Copilot-specific rules. State package-manager commands, the smallest test, generated-file rules, forbidden paths, migration policy, and required PR evidence. Long context consumes the model budget needed for the change.

Sandbox and approvals are different controls

Codex documents the distinction clearly: the sandbox determines which files and network resources commands can access, while approvals determine when Codex pauses before an action. The common local profile is workspace-write with on-request approvals. read-only is appropriate for exploration or a CI review that must not edit. danger-full-access and the --yolo alias remove the safety boundary and should be reserved for an isolated environment.

For a local implementation, make the contract explicit:

codex --sandbox workspace-write --ask-for-approval on-request

In CI, codex exec is read-only by default. Add --sandbox workspace-write only when a patch is required. Use --ask-for-approval never only with a controlled runner, checkout, command allowlist, and output path. Do not copy deprecated --full-auto into new scripts.

Claude Code uses tiered permissions. Read-only files and built-in read-only shell commands do not prompt in Manual mode. Edits, general Bash, web fetches, and searches can require approval. Client-side allow, ask, and deny rules are joined by Manual, Plan, Auto, and isolated-environment bypass modes. Sandboxed Bash adds filesystem and network isolation through /sandbox.

Copilot CLI asks before tools that edit or execute files, while read-only searches and reads are automatic. Permissions can scope tools, paths, and URLs. Local sandboxing is a separate experimental control, and GitHub also documents an ephemeral cloud sandbox. Check /sandbox policy and effective permissions before autonomous work.

Grant capability in layers: repository reads, exact formatter and test commands, then branch or worktree writes. Keep network, package installation, credentials, pushes, and deployments separate. A sandbox limits reach, not semantic correctness.

Tools, MCP, and automation hooks

All three use shell, file operations, and repository search. Codex documents skills, plugins, MCP, and a GitHub Action. Claude Code documents MCP, skills, hooks, and subagents. Copilot CLI documents MCP, skills, plugins, custom agents, hooks, and a built-in GitHub MCP server.

Treat each extension as code in the workflow. Review its source, scope credentials, and decide whether it belongs to the implementer or a reviewer. An MCP server that creates tickets or merges PRs is different from a read-only documentation server. Connections are not safe by default.

Hooks can format after edits or run a fast test at task completion. Keep them deterministic and short. Do not hide deployment or destructive migration in an unexplained hook.

Tests are an evidence loop, not a completion phrase

A good prompt names behavior, fixtures, commands, and stop conditions. Ask the agent to inspect tests, add a failing expired-session case, make the smallest fix, run the focused test, and run required checks. Require the command and exit status in the report. If the focused test already passes, ask why instead of requesting a second implementation.

Claude Code documents finding uncovered code, scaffolding, edge cases, running tests, and fixing failures. Codex and Copilot CLI can run repository commands when permissions and tools allow. Generated tests are not proof of coverage. A human checks contracts, fixtures, integration paths, and security cases.

Use three layers when possible: focused tests for feedback, a package or service suite for integration effects, and required PR checks as the merge gate. Bound repair attempts and report original failure output. Repeating a flaky command is not new evidence.

Diff, review, and pull requests

Review starts before a PR. Ask for changed files, invariants, tests, and gaps. Compare with the task, then inspect the Git diff yourself. A summary is not the source of truth.

Codex documents /review for uncommitted changes, commits, or branch comparisons, with findings reported without changing the tree. Its GitHub Action documentation includes a workflow that reviews pull requests and posts results. Local PR creation still uses ordinary Git or GitHub tools and permissions.

Claude Code documents staging, commits, branches, and PRs. Its Actions integration supports @claude in issues or PR comments, issue-to-PR work, and review workflows. Keep the token and repository permissions narrow, and retain normal CI gates.

Copilot CLI documents /review, /pr create, and /pr fix feedback, plus conflict and CI fixes. /delegate sends work to the cloud agent, which opens a draft PR and continues remotely. These command paths do not promise a mergeable PR.

Separate “prepare” from “publish.” Let the agent create a branch, patch, tests, and draft description. Keep pushing, labeling, approving, and merging behind a human or protected identity. Include task, files, commands, results, risks, and untested areas in the PR.

CI and repeatability

Codex’s non-interactive mode is designed for pipelines. It separates final output from progress, emits JSON Lines, writes the last message, and accepts an output schema. Handle authentication, logs, and failures safely.

Claude Code runs with -p and in Actions. Use a read-only review job for untrusted PRs and a separate write job for authorized maintenance. Trigger and token rules remain part of the boundary.

Copilot CLI offers -p, output formats, autopilot, and Actions. --max-autopilot-continues bounds continuation. In Actions, choose the billing identity and write-capable token. A model response is not a CI pass until the real test job succeeds.

Security and cost boundaries

Prompt injection can arrive through an issue, fixture, README, generated file, or web page. Do not grant broad network access or production credentials for source inspection. Deny secret paths, avoid printing environment variables, separate package installation from tests, and review MCP servers and hooks as supply-chain dependencies.

Codex limits and credit options vary by plan and task size. Claude Code distinguishes API billing from subscription usage and exposes /usage; extended thinking and long context can increase consumption. Copilot CLI uses GitHub AI Credits and documents --max-ai-credits. These accounting systems are not directly comparable.

Set a workflow budget. Use lower effort for mapping and a stronger model for high-risk decisions. Cap retries, parallel agents, autopilot, and cloud runtime. Clear or compact sessions between unrelated tasks. Report engineering cost and human review time, not only tokens.

Workflows that fit the controls

For a local change, start any of the three in plan or read-only mode. Have the agent map the repository, quote relevant instructions, and propose files and tests. Approve the smallest set, run focused and required checks, and review the diff before a PR command.

For GitHub-first PR feedback and CI fixes, Copilot CLI documents a direct /pr lifecycle. For comment-triggered work, Claude Code Actions and Codex’s PR review Action provide documented paths. For structured local output, Codex exec documents JSONL and schemas. These are interface-fit statements, not rankings.

For sensitive code, choose the deployment mode your organization can enforce. A read-only reviewer in a locked-down runner may be safer than an autonomous local session. Put policy in CI and provider controls, not only in prose. See AGENTS.md and coding agents, AI-agent evaluations, and production AI-agent architecture.

A small operating contract

Before starting, define the repository, branch, allowed paths, test command, network needs, repair limit, and PR owner. Require visible tools, bounded approvals, and a distinction between repository facts and guesses. End with the diff, test evidence, risks, and usage signal. Let the reviewer and CI decide readiness.