The pull request that knows its sessions

The diff is the least interesting part

A pull request used to be a person's work, summarized by that person. You read the description, you knew who to ask, and the reasoning lived in their head a desk away. When an agent wrote the change, the description is the agent's, the reasoning is in a transcript, and the person whose name is on the PR may have steered it in ten messages and read none of the code. The question a reviewer actually has is not “what changed” but “what was this agent trying to do, and did it check”. GitHub cannot answer that. The session can.

So codecast treats a pull request the way it treats a session or a task: as an object with an address, a state, and links to the conversations around it. Every repository in codecast has a Pull requests tab, filtered by Open, Merged, Closed, Mine and Shepherded. Here it is on our own repository today:

One open pull request, its checks failing, and a tag that says shepherded: a session owns it. That tag is the whole idea.

Everything known about one

Open one and you get the page a reviewer wants before opening the diff. Across the top: Checks, Review, Merge, Open comments and Diff, each with its verdict. Below that, tabs for Conversation, Files, Commits and Checks, and beside them the sessions that made the change. Here is a teammate's pull request from September, #47, on the Checks tab, with its shepherd session on the right:

That pull request was linked to seven sessions. Judging by their titles: a crash fix, two verification passes across machines, a React error debug, and three that read or touched the change without being about it. Each opens with a click. The first comment on the GitHub side is titled Codecast Conversation: a link from the pull request back to the session that made it. The paper trail runs both ways. (A terminal gets the same summary from cast pr show.)

A timeline, not a notification pile

GitHub tells you a check failed by email, one at a time, out of order. Codecast keeps the pull request's history as a timeline on its Conversation tab, with a marker for what changed since you last looked, and a comment box whose comments are mirrored to GitHub. The shepherd session sees the same events as rows in its own transcript. The day #47 had looked like this, read top down:

1. Opened.
2. A security check and a test job fail; the branch falls behind main.
3. The author pushes a fix, and the pull request merges cleanly again.
4. The same two checks fail again, and a third joins them.
5. By morning it is behind main once more.

That is a pull request waiting for its owner. Which brings us to the part that is new.

A review that wakes the author

When a session owns a pull request, codecast calls it the shepherd. On a pull request with none, the header offers Assign a shepherd session and lists the sessions that worked on it; the shipping flow assigns one itself when it opens the pull request. Once set, the header names the shepherd and carries a switch, Wakes on changes or Paused:

From then on the session is woken when the pull request moves: a check goes red, the branch falls behind, and above all, someone reviews it. Reviewing happens on the same page. On the Files tab, click a line and choose Start a review; later notes go in with Add to review. The Review button opens Finish your review, where the notes go out as one verdict: Comment, Approve or Request changes. It lands on GitHub under the reviewer's own account, so the verdict is theirs. Or choose Send to session, and the notes go only to the shepherd, as one message, with nothing posted to GitHub.

Either way, if the pull request has a shepherd, the whole review, verdict and every note, arrives in that session the moment it is sent. The agent that wrote the change reads the review, makes each fix, pushes to the same branch, replies on the threads it addressed, and resolves them. The reviewer sees resolutions, not silence. Agents that review each other use the same batch from a terminal, with cast pr comment --hold and cast pr review.

The shepherd on #47 was off, which is why it sat behind main all night with three red checks and nobody woke up. Toggle it on, and the next failed check becomes a turn in the session that knows the code.

Why this is a team feature

Every previous post on this blog was about one person's agents. This one is about the seam between people. A pull request is where a teammate first meets work they did not watch happen, and the question they bring is always the same: what was the agent trying to do? Linking the PR to its sessions answers it without a meeting. Letting a review wake the agent answers the follow-up, “who fixes it”, without a person relaying comments into a terminal. The record that made a session searchable last month is the same record that makes its pull request reviewable now.

Codecast is where your team sees, steers, and remembers every coding agent session — any agent, any machine.

All three screenshots are the pull request pages in the codecast web app for the public repository codecast-sh/codecast, whose pull requests and author handles are public on GitHub: #47's Checks tab on 2026-09-17, cropped to the content column with the author's avatar blurred, and the Pull requests tab and #52's header on 2026-10-09. The linked sessions and the event history of #47 were read with cast pr show and cast pr events on 2026-09-17; the timeline above summarizes those events in order.