The commits and merge requests a task produced

A task finishes a stage, and the next question is always the same: where’s the code? CodeHerder keeps a record of every commit and every merge request a task’s sessions produced, and you can read it from the web app or the CLI.

On the task page

Open a task and look for two panels: Merge requests, subtitled “opened by this task’s sessions”, and Commits, subtitled “made by this task’s sessions”. Each lists rows in the same shape:

• Merge requests — Number, Title, Repo, and when it was last updated.
• Commits — SHA, commit message, author, repo, and when it was committed. For who the author is, see Whose name is on a commit.

The SHA and the merge-request number link out to the provider’s own page, when CodeHerder has resolved one. The Repo cell links to that repo’s page inside CodeHerder. Before anything’s landed, each panel shows an empty state — “No merge requests recorded yet.” or “No commits recorded yet.” — rather than an error.

A session page carries the identical pair of panels, scoped to just that one session’s sandbox instead of the whole task.

Whose name is on a commit

Each commit has two names: an author and a committer. CodeHerder sets both when it starts an agent session, and a launch configuration can’t override them. The one exception is a repo with its own commit identity.

• Committer — the agent. Its name is the agent’s display name followed by “(CodeHerder agent)”, for example “Ada (CodeHerder agent)”. The email is a placeholder address that can’t receive mail.
• Author — the person who filed the original task. CodeHerder follows “filed by” links up from the task to the first task a person filed, and uses that person. If it finds none, it uses the task’s creator when that’s a person. The name is their display name, or their email address if they have no display name.

That person needs a verified email address. If they don’t have one, or no person filed any task in the chain (for example, an integration or webhook filed it), the agent is both author and committer.

A repo can carry a commit identity. When it does, an agent’s commits in that repo use that name and email as both author and committer, and the rules above don’t apply to that repo. Other repos in the same session keep them. A workspace owner or admin sets it with the CLI; see Setting a commit identity for a repo.

In a session you start on a device as an agent, you’re the author if your email address is verified, because you started it. The agent is still the committer. See Start a session on a device.

To see both names on a commit in a checkout:

git log --format='%h  author: %an  committer: %cn'

3f9c2ab  author: Sam Rivera  committer: Ada (CodeHerder agent)

A few limits to know:

• The merge request isn’t in the agent’s name. Your git host shows it as opened by the owner of the git token on the device that pushed it. See Git tokens on a device.
• The author line is attribution, not proof. Commits aren’t signed, and an agent process can change the identity it commits with. Rely on review and branch protection, not on the name. See Reviewing an agent’s work.
• Older commits can differ. Commits from sessions that started before this behaviour shipped can show the agent as author.

From the CLI

ch task commits <taskId>
ch task merge-requests <taskId>

ch task commits lists every commit the task’s sessions made, across every sandbox the task worked in, newest first. ch task merge-requests lists every merge request those sessions produced, the same way.

Both lists are capped and don’t page — unlike most ch list commands, neither takes --limit or --cursor. A task’s own git history is small enough that CodeHerder just hands you the whole thing.

Inside an agent session, <taskId> defaults from CH_TASK_ID, so the bare form works without naming it:

ch task commits
ch task merge-requests

Narrowing to one sandbox

A task can attach more than one sandbox over its lifetime — a rework pass gets its own, for instance. To see just one sandbox’s slice instead of the whole task’s, use the sandbox-scoped equivalents:

ch sandbox commits <sandboxId>
ch sandbox merge-requests <sandboxId>

These skip --limit/--cursor too. Inside an agent session, <sandboxId> defaults from CH_SANDBOX_ID the same way <taskId> defaults from CH_TASK_ID, so the bare form works there too.

A merge ref is not the same as a merge request

ch task merge-refs (see How the work lands) is a different, narrower thing: it’s the task’s own recorded pointer to the merge request that decides whether the task counts as landed, one per repo. ch task merge-requests, described here, is everything CodeHerder has observed — every merge request any of the task’s sessions opened, whether or not it’s the one the task is waiting on. Reviewing a task that’s ready to merge still means checking its merge refs; use this page’s commands when you want the fuller picture of everything the task touched. See Reviewing an agent’s work for the merge checkpoint itself.

Why a list can be incomplete

A merge request lands in these lists one of two ways: an agent reports it the moment it opens one, or a periodic sweep finds it by matching branches against your git host. The self-reported half shows up right away and needs nothing configured. The sweep-discovered half needs a git-host integration connected for that repo’s host (see Integrations) — without one, CodeHerder has no way to look up merge requests it wasn’t told about directly, and only the self-reported ones will appear.

Related guides

• What CodeHerder built in this repo — the same kind of record at the whole-repo level, across every task and everyone else’s work too
• Tasks that span several repositories — how one task’s work spreads across repos, and how each repo’s merge request is tracked
• Reviewing an agent’s work — where the merge checkpoint fits into a task’s workflow