Steer a coding agent mid-run, and after the PR merges

Ten minutes into a run you remember the helper the agent should have used, and you want to tell it without starting over. Most hosted agents now take a message like that, and most also pick up review comments and CI failures on the pull request they opened. They differ on when your message lands, and on what happens after the merge, which almost none of them document. This post covers how to steer a coding agent mid-run, what happens to a message you send while it works, and what you can still ask for once the PR has merged.

We build Sinatra, so most of the detail is about how Sinatra handles this. The section on other agents links every claim to the vendor's own docs.

Product details checked October 2026 against Sinatra's docs and changelog and each vendor's own pages, linked throughout.

In Sinatra a task is a conversation. Each time you ask, the agent reads the conversation so far and decides whether you need an answer, a question back, a plan or code. The task keeps taking replies while its PR is open and after it merges, and one task can open more than one PR. Merging or closing a PR doesn't end the task.

The dashboard shows each task in one of four states: In progress, Queued, Needs your input and Idle. A task whose PR is waiting for review usually sits in Idle until someone replies, and a reply starts it working again.

You steer Sinatra by replying where the task started, on the ticket or in the thread.

On Linear, reply in the issue's agent session, reply in the thread of a comment Sinatra posted, or mention Sinatra in a new comment. The Linear walkthrough covers the rest of that loop.

On GitHub, comment on the issue that carries the Sinatra label (sinatraai). Once a PR is open, code feedback goes on the PR, where a comment wakes Sinatra only when it mentions @sinatraai, comes from a workspace member and asks for something. A review that requests changes also sends it back to work.

In Slack, reply in the task's thread. A reply that mentions @Sinatra always reaches it. One without a mention reaches it when Sinatra judges it's meant for it, like an answer to its question or a pasted stack trace, while teammates talking to each other are left alone. The Slack walkthrough goes through it step by step.

A message sent while the agent is running reaches the running agent. That works with both engines Sinatra runs, Claude Code and oh-my-pi, and it's been true for Claude Code since the October 12 change that made tasks outlive their PRs.

You don't pick when your message applies. Sinatra reads it and decides between three options: hand it to the agent right away, fold it in before the run finishes, or run it as its own next turn once the current one ends. When it waits, Sinatra tells you.

Roughly, a correction to the work in progress ("use the existing date helper, not a new one") needs to reach the agent now, an extra requirement for the same change ("also cover the empty string") can be folded in before the run ends, and a separate request ("after this, update the README") makes more sense as a turn of its own.

A message from someone who can't spend the running agent's credentials becomes their own next turn instead of being refused.

If you want to throw the work away and start again, send the literal word restart (in Slack, a mention with only that word). That's destructive on purpose: Sinatra abandons the sandbox, deletes its branch, closes the existing PR and begins the ticket again. Any other message continues the work on the same branch.

After a PR merges, Sinatra says so on the ticket, and the task goes on taking replies. "The fix works, but the same bug is in the CSV export too" on a merged issue doesn't need a new ticket. The agent already has the conversation, and it can open a second PR for the same task. On Linear, marking the issue Done while its PR is still open gets the reply "Issue marked Done. Reply here if you need anything else."

Replies after a run has ended start the next turn, and that turn counts against your plan's tasks-at-a-time limit like any other. If the plan is full, it's queued and starts on its own when a running task finishes.

A failed GitHub check suite on Sinatra's PR gets a fix as its own turn, after any work people have asked for. Sinatra explains on the PR what it did: pushed a fix to the branch, reran the failed jobs because the failure looked flaky, or left a note that the failure was already there or unrelated. It stops after ci.max_rework fixes in a row with no message from a person (two by default) and says so on the PR. Your next reply resets the count. The CI post goes into how that loop works.

Tasks started from the sinatra CLI, from an MCP client such as Claude Code or claude.ai, or from the HTTP API work differently. A message sent while one of those is running doesn't change the current turn. It waits and runs as the next turn. If you expect to change direction halfway through, start the work from a Linear issue, a labeled GitHub issue or a Slack thread.

Stopping works from more places than steering does. On Linear, the agent session's Stop control stops the current work and keeps the task. On GitHub, removing the label or closing the issue cancels the run. Slack has no stop control, so you stop a Slack task from the dashboard, with sinatra stop <task-id>, or through the MCP or HTTP API, and then mention Sinatra in the thread to carry on.

The table compares the hosted agents we checked on when a mid-run message lands, where you can send it from, and what happens once the PR is open.

Agent	A message sent while it runs	Where you send it	After the PR
Cursor Cloud Agents	Waits for the next tool call	Web, desktop, Slack, Linear, @cursor on a PR	Can watch its own PR for review comments and CI
GitHub Copilot cloud agent	Applied after the current tool call; each message uses AI credits	The session on GitHub, @copilot on the PR	@copilot on the PR, with context from earlier sessions
OpenAI Codex	The app and CLI can steer or wait, by setting; not documented for cloud tasks	ChatGPT, Codex, Slack and Linear threads	@codex on a PR starts a new cloud chat
Claude Code on the web	Queued until Claude reads it	Web, mobile, desktop, claude -p ... --cloud ID	Auto-fix watches the PR for failed checks and review comments
Devin	Web app: queued, sent when Devin is free; CLI: read at its next step	Web app, Slack, CLI, PR comments	Answers PR comments until archived; merged PR comments ignored
Google Jules	"At any point," timing not documented	The chat box	Answers PR comments, fixes CI
Linear coding sessions	Steering supported, timing not documented	The session, including on mobile	Steer before or after the PR opens
Sinatra	Sinatra decides: now, before the run ends, or next turn	Linear, GitHub, Slack; CLI, MCP and API messages wait	Same task takes replies after the merge and can open another PR

Cursor's August changelog says you can "send a message to steer the agent while it's working without interruption," and that "Follow-ups wait for the next tool call instead of cutting the agent off mid-action." You also steer it from Slack, from Linear ("mention @Cursor in a Linear comment to provide additional guidance to a running Cloud Agent," per its Linear docs), or by commenting @cursor on a PR. Its capabilities page lets an agent open a PR and then "respond to review comments and CI failures," with events arriving "as follow-ups in the same conversation." Our Cursor Cloud Agents post goes deeper.

GitHub's agent management docs say "Copilot implements your input after it finishes its current tool call. Each steering message consumes AI credits." There's a Stop session button that ends the Actions run and keeps the commits already pushed. After the PR, you mention @copilot on it, and "Copilot remembers context from previous sessions on the same pull request." Comments added to the original issue after you assign it aren't seen, per its cloud agent docs.

OpenAI documents steering for the Codex app and CLI. Its settings reference has a follow-up setting that chooses "whether a message sent while ChatGPT works should steer the current run or wait for the next run." The cloud page only says you can "request follow-up changes," so we couldn't confirm the same behavior for a cloud task. On GitHub, mentioning @codex on a pull request "starts a legacy cloud chat using your pull request as context," per the GitHub integration docs, which is a new chat rather than the original task.

Claude Code on the web queues: "If you send a message while Claude is working, the message queues until Claude reads it," per Anthropic's web docs. After the PR, auto-fix subscribes to its activity, and "when a check fails or a reviewer leaves a comment, Claude investigates and pushes a fix if one is clear."

Devin's web app queues by default, and release notes say queued messages are sent "immediately when Devin becomes available." The Devin CLI hands a message "to the running turn instead of waiting in the queue: Devin reads it at its next step," per its CLI changelog. On GitHub, Devin "automatically responds to comments on PRs its sessions are working on, as long as the session has not been archived," but "comments on issues, or on closed or merged PRs, are ignored," per its GitHub docs. Devin is the only vendor here that documents what a comment on a merged PR does.

Jules says "At any point, you can use the chat box to talk to Jules," in its plan review docs, and its changelog adds that it reads and responds to PR comments and fixes CI failures on its own PRs. Linear's coding sessions docs say you can "steer or follow up with the agent," and a recent changelog adds "before or after a pull request is opened." Neither says exactly when a mid-run message applies.

Local Claude Code is still the most direct way to steer. Esc stops the current response or tool call "so you can redirect," and "Claude keeps the work done so far," per its interactive mode docs. If you want to watch every step and cut in, run an agent on your own machine.

Cursor and Copilot tell you exactly when your message lands: at the next tool call. Codex lets you choose between steering and waiting. Sinatra decides for you, so you can't force a message to apply immediately.

Devin lets you stop a session and "take over and start using the IDE yourself," per its session tools docs, and in Slack the sleep keyword pauses it, per its Slack docs. Copilot has a Stop session button next to the session.

Cursor, Claude Code on the web and Jules can watch their own PRs and react to CI failures and review comments. Sinatra fixes failed checks as their own turn, but review comments on the PR reach it only when they mention @sinatraai or request changes.

The free plan is enough to see it: start free, hand Sinatra a ticket, and reply while it's working. The steering docs have the details.