Skip to main content
Manage trails: project intent, the repository branches linked to it, discussions, findings, approvals, and merges.
entire trail may not appear in entire help; run entire trail --help to see its subcommands. Coding agents can run entire agent-help trail for the same surface with agent-specific guidance. Trail commands call the Entire API with your saved login, so run entire login first. They need network access and access to the credential store where the login is saved.

Trails and Changes

A project trail holds intent: a title, description, type, priority, assignees, and an open or closed status. It can span several repositories. Each repository branch linked to the trail is a change, and each change is reviewed, approved, and merged on its own. Project trails and changes are numbered separately. Trail numbers are project-wide, so trail 12 means the same trail from any repository in the project. Change numbers are per repository and are written as <repo>/<number>. Commands that take a <trail> argument accept these selectors: Do not pass an entire.com trail URL as a selector. Use the number from the URL instead, and add --project when the project is not the current repository’s.

Shared Flags

These flags apply to every entire trail subcommand. --repo and --branch select one repository branch of a trail for checkout, resume, finding, watch, approve, approvals, and merge. They do not aggregate across every repository on the trail.

trail create

Create a trail and publish its branch.
create makes a repository-scoped trail, then links a branch to it. In the current repository it publishes the local branch first, so no separate commit or push is required. It uses the current feature branch, or derives a new branch name from the title when you are on the base branch. Use --branch to choose a branch, or --no-branch for intent only. With --no-branch, the current or --repo repository becomes the trail’s scope, which requires write access to that repository. --project without --repo creates unscoped intent instead, which requires project management permission. With --repo, no local branch is published. Link existing remote work, or pass --branch-action create to create the branch on the server from --base. create does not commit changes or change your local checkout. Branches are preserved if creation fails.
With a branch, --idempotency-key applies only to the link step. If linking fails after the trail is created, retry with entire trail link rather than creating another trail.

trail list

List trails in a project.
list shows trails in one project, newest update first, and does not need a checkout. --project is required even inside a clone. --repo only filters within that project. Omitting --status includes every lifecycle state.

trail show

Show trail intent and its repositories and branches.
Pass a project trail number or ID, or a <repo>/<number> change to show its parent trail. Without a selector, show follows the current branch to its trail. With --json, each entry in changes[] is one repository branch with its own URL.

trail update

Update a trail’s intent and lifecycle.
Without a selector, update acts on the current branch’s trail. Pass at least one field to change.
Link a repository branch to a trail.
link attaches an existing remote branch to a project trail, given by number or ID. --branch defaults to the current branch. Use --branch-action create to create the branch on the server from --base. Existing work and reviews are preserved. A branch that already belongs to another trail is rejected.
Unlink a repository branch without deleting its work.
unlink removes a repository branch from a trail. The branch, code, reviews, and sessions are preserved. A trail with one open change unlinks it. With several, they are listed so you can pass one as <repo>/<number> or select it with --branch.

trail checkout

Check out a trail’s branch.
The trail can be given as an argument or with --trail. Without one, the current branch’s trail is used. --branch selects the working branch; otherwise the current branch, or the trail’s only branch in this repository, is selected. When neither applies, the open changes are listed so you can pass one as <repo>/<number>. Remote-only branches are fetched. checkout must run inside a clone of the trail’s repository. The trail is looked up against that clone’s origin remote, and --repo is not accepted. With --worktree, the branch is checked out into a Git worktree under .entire/worktrees at the repository root instead of switching the current checkout. Gitignored files that match .worktreeinclude patterns are copied into the worktree. In a terminal, the command prints a cd command for the new worktree. When standard output is not a terminal, it prints only the worktree path.

trail resume

Resume a trail’s agent session.
The trail can be given as an argument or with --trail. Without one, the current branch’s trail is used. When several branches match, pass --branch. In an interactive terminal, resume shows the trail context, restores the checkpoint sessions on the trail branch, and asks whether to start the agent. If the checkpoint has several sessions, you choose which one to start. Non-interactive runs show the same context and print resume commands for the latest checkpoint on the trail branch. Use --session or --checkpoint to resume an exact session or checkpoint. With a trail number or ID, --branch asserts the branch you expect the trail to be attached to. If it does not match, resume stops before checking anything out.
--force overwrites existing local session logs with the versions stored in checkpoints.

trail watch

Tail events for a trail’s selected repository branch.
watch subscribes to the trail’s event stream for the selected repository branch and prints events as they arrive. It reconnects automatically when the server caps the connection, about every 50 seconds, and on transient network errors. Without a selector, the current branch’s trail is used.

trail comment

Discuss the whole trail across repositories.
Comments are discussions between people on the whole trail. Agents report through findings instead: when Entire detects an agent session, the write subcommands (add, reply, edit, delete, resolve, unresolve) are refused, while list and show still work. These flags apply to every trail comment subcommand: Every subcommand also accepts --json to output raw JSON instead of a table.

trail comment list

List the trail’s discussions.

trail comment show

Show a discussion and its messages.

trail comment add

Start a discussion on the trail.

trail comment reply

Reply to a discussion.

trail comment edit

Edit a discussion message.

trail comment delete

Delete a discussion message.

trail comment resolve

Resolve a discussion.

trail comment unresolve

Reopen a resolved discussion.

trail approve

Approve a trail’s selected repository branch.
Without a selector, the current branch’s trail is used. Only the selected branch is approved, not every repository on the trail. The branch must be open.

trail approvals

List approval decisions on a trail’s selected repository branch.

trail merge

Merge one of a trail’s changes into its base branch.
Without a selector, merge merges the current branch’s change. A trail with one open change merges it, in any repository. With several, they are listed with their review state so you can pass one as <repo>/<number> or select it with --branch and --repo. Each change merges on its own; merging one never merges the trail’s other changes. The trail’s gates are checked first: approvals, CI checks, the base branch’s CI, being up to date, and any other configured gates. When a blocking gate fails or is still pending, the blocking gates are listed and nothing is merged. A change that conflicts with its base is never merged; resolve the conflicts first. --dry-run only reports whether the change can be merged. It exits non-zero when the merge would be refused, so it can gate CI. After merging a change in a repository hosted on Entire, the server deletes the trail’s branch when the repository’s delete-branch-on-merge setting is on. Your local branch is not touched. --delete-branch and --no-delete-branch override that setting for one merge. Before deleting the branch, the server moves any open trails based on it onto this trail’s base, and keeps the branch when one of them cannot be moved. A GitHub-backed trail’s branch follows GitHub’s own auto-delete setting, so both flags are refused there.
--force bypasses blocking gates and is recorded on the trail. The repository’s bypass policy decides who may use it. Without a terminal to confirm in, or with --json, --force also requires --yes.

trail finding

Manage a trail’s agent findings.
A finding is an issue raised against a trail’s branch, typically by a runner or an agent review. Findings apply only to the selected repository branch, not the whole trail. Run entire trail finding with no subcommand to show the finding dashboard for the current branch’s trail; it takes the same filter flags as trail finding list. These flags apply to every trail finding subcommand:

trail finding list

List findings for a trail.
By default, list shows open findings on the current code version.

trail finding show

Show a finding.

trail finding add

Create a finding on a trail.
A finding can carry a location and a suggested change. A patch must modify a single existing file in this worktree; when --file is omitted, the location defaults to the file the patch modifies.

trail finding apply

Apply a finding’s unified-diff suggestion to the current worktree.
By default, apply only changes files. Pass --resolve to also mark the finding resolved once the patch applies. apply patches this clone, so --repo is not accepted.

trail finding resolve

Resolve a finding.

trail finding dismiss

Dismiss a finding.

trail finding reopen

Reopen a resolved or dismissed finding.

trail finding update

Update a finding’s metadata. Pass at least one of --body, --severity, or --confidence.
When the findings gate is configured, open findings at or above its severity threshold block the merge until each one is resolved or dismissed. See Gates.

Continue With

Trails overview

Learn how trails group intent, branches, and checkpoints.

Agents

Configure the automated evaluations that run on a trail.

Gates

Configure the checks a change must pass before it merges.

runner

Set up the runners that raise findings on a trail.