List every git repository tracked in GitWarren, each with its live git state (whether the folder still exists, whether it is still a repository, and the current branch). Git state is read fresh on every call and is never cached.

Fetch one tracked repository by id, with its live git state.

Start tracking a git repository. path may be any directory inside the working tree - it is resolved to the repository root before being stored, so the same repository cannot be added twice under two different paths. name defaults to the folder name. Fails with NOT_A_GIT_REPOSITORY if the path is not inside a git repository.

Rename a tracked repository, or repoint it at a moved working copy. Provide at least one of name or path. A new path is validated and resolved exactly as it is when adding.

Stop tracking a repository. This only removes it from GitWarren - the working copy on disk is never touched.

List reviews, newest activity first. Filter with repositoryId and/or status ("open" or "closed"); omit both to list every review across all tracked repositories. A review records the two refs being compared, not the commits they resolved to - read the repository with git to see the actual changes.

Each result carries guiUrl, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by gitwarren serve or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one that works.

When this machine is reachable on the user's tailnet, results also carry webUrl. The two links are for two situations and neither replaces the other: guiUrl opens GitWarren on the machine the user is sitting at, which is the right one when that is this machine; webUrl opens the same review in a browser from any of their devices - a phone, a laptop across the room - because it names this machine on their tailnet. Offer webUrl when the user is not at this machine, and both when you do not know.

Fetch one review by id, with the repository it belongs to attached (including the repository path, so the changes can be inspected with git directly).

Each result carries guiUrl, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by gitwarren serve or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one that works.

When this machine is reachable on the user's tailnet, results also carry webUrl. The two links are for two situations and neither replaces the other: guiUrl opens GitWarren on the machine the user is sitting at, which is the right one when that is this machine; webUrl opens the same review in a browser from any of their devices - a phone, a laptop across the room - because it names this machine on their tailnet. Offer webUrl when the user is not at this machine, and both when you do not know.

Open a review comparing two refs in a tracked repository. baseRef is what the changes are measured against (usually the trunk) and headRef is the branch under review; the diff is taken from their merge base, like a pull request. Both refs must exist and share history, or the call fails with INVALID_INPUT. title defaults to " into ". If the head branch is checked out in a worktree, its uncommitted changes are part of the review as well - a review can be opened on work that has never been committed. Passing the same ref as both endpoints is allowed and does exactly that: the review then holds only the uncommitted work on that ref, and its title defaults to "Uncommitted work on ".

Each result carries guiUrl, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by gitwarren serve or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one that works.

When this machine is reachable on the user's tailnet, results also carry webUrl. The two links are for two situations and neither replaces the other: guiUrl opens GitWarren on the machine the user is sitting at, which is the right one when that is this machine; webUrl opens the same review in a browser from any of their devices - a phone, a laptop across the room - because it names this machine on their tailnet. Offer webUrl when the user is not at this machine, and both when you do not know.

Change a review's title, description or endpoints, or set its status to "closed" or "open" again. Provide at least one field. New refs are validated exactly as they are on creation.

Each result carries guiUrl, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by gitwarren serve or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one that works.

When this machine is reachable on the user's tailnet, results also carry webUrl. The two links are for two situations and neither replaces the other: guiUrl opens GitWarren on the machine the user is sitting at, which is the right one when that is this machine; webUrl opens the same review in a browser from any of their devices - a phone, a laptop across the room - because it names this machine on their tailnet. Offer webUrl when the user is not at this machine, and both when you do not know.

Delete a review. This removes only the review record - no branch, commit or file in the repository is touched. To file a finished review away without deleting it, set its status to "closed" instead.

Show how comments from this session will be attributed, and optionally set a label for the session. The tool name ("Claude Code", "Codex", ...) is taken from the MCP handshake and cannot be changed - it is what makes attribution consistent across sessions. label is a short handle for this session ("auth-refactor"), worth setting when more than one agent is working the same review; it is remembered until this server process exits.

Every discussion on a review: review-level threads and line comments alike, each with its full message history and who wrote each message. Line threads also carry an anchor saying where they land in the code as it stands right now - "anchored" (the line is unchanged), "moved" (the code shifted and anchor.line is its current line) or "outdated" (the line is gone, so the comment may be about code that has since been rewritten). Threads about files the diff does not contain are resolved against those files at the head rather than against the patch, so a comment on unchanged code reports an honest anchor too. Check the anchor before acting on a line comment. An outdated one still carries anchorSnapshot, the code as it read when the comment was written, which is how to tell what was being objected to before it was rewritten.

A body may contain images, written as markdown pointing at a gitwarren://attachment/... URL - that is an internal token, not something to fetch. Each one is resolved in the comment's attachments array, where path is a real file on disk: read it with your own image tools. alt is the description whoever attached it wrote, and is worth reading first - it is often enough on its own, and it is all you get if you cannot see images.

Each result carries guiUrl, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by gitwarren serve or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one that works.

When this machine is reachable on the user's tailnet, results also carry webUrl. The two links are for two situations and neither replaces the other: guiUrl opens GitWarren on the machine the user is sitting at, which is the right one when that is this machine; webUrl opens the same review in a browser from any of their devices - a phone, a laptop across the room - because it names this machine on their tailnet. Offer webUrl when the user is not at this machine, and both when you do not know.

Start a new discussion on a review. Omit filePath and line for a comment on the review as a whole; give both to attach it to a line, the way a pull-request review comment works. side picks which side of the diff line counts on - "head" (the default) for the code as it will be, "base" to remark on a line the change removed. Add startLine to comment on a block rather than a single line; line is then the last line of it, and the one the whole range follows if the code moves. The line is not required to be part of the diff. A line the patch does not print is looked up in the file itself at the head, so a remark on code this branch did not touch anchors and follows that code exactly as one on a changed line does - people read these in the review's Browse files tab. Only a line that is in neither the diff nor the file (past the end of it, or on the "base" side outside the patch) is kept without an anchor; the returned thread says which happened. Comments are attributed automatically from the MCP handshake - see agent_identity.

To include a screenshot, write the file to disk first, then reference it as an ordinary markdown image:

The dropdown renders behind the modal:

![dropdown behind modal](/tmp/dropdown-bug.png)

The file is copied into GitWarren and the path rewritten, so the image survives /tmp being cleaned. Always write alt text - it is what agents without vision see.

If the path contains a space - "Screen Shot 2026-09-01 at 10.32.14.png", as macOS names screenshots - wrap it in angle brackets, or markdown does not read it as an image at all and it is left as plain text:

![login screen](</tmp/Screen Shot 2026-09-01 at 10.32.14.png>)

PNG, JPEG, GIF and WebP are accepted, up to 10 MB. A path that does not resolve is left in the text as written rather than failing the call, so check the returned body if it matters.

Each result carries guiUrl, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by gitwarren serve or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one that works.

When this machine is reachable on the user's tailnet, results also carry webUrl. The two links are for two situations and neither replaces the other: guiUrl opens GitWarren on the machine the user is sitting at, which is the right one when that is this machine; webUrl opens the same review in a browser from any of their devices - a phone, a laptop across the room - because it names this machine on their tailnet. Offer webUrl when the user is not at this machine, and both when you do not know.

Add a message to an existing thread. Use this rather than opening a new thread when responding to something someone already raised, so the discussion stays in one place. Thread ids come from list_review_comments.

To include a screenshot, write the file to disk first, then reference it as an ordinary markdown image:

The dropdown renders behind the modal:

![dropdown behind modal](/tmp/dropdown-bug.png)

The file is copied into GitWarren and the path rewritten, so the image survives /tmp being cleaned. Always write alt text - it is what agents without vision see.

If the path contains a space - "Screen Shot 2026-09-01 at 10.32.14.png", as macOS names screenshots - wrap it in angle brackets, or markdown does not read it as an image at all and it is left as plain text:

![login screen](</tmp/Screen Shot 2026-09-01 at 10.32.14.png>)

PNG, JPEG, GIF and WebP are accepted, up to 10 MB. A path that does not resolve is left in the text as written rather than failing the call, so check the returned body if it matters.

Each result carries guiUrl, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by gitwarren serve or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one that works.

When this machine is reachable on the user's tailnet, results also carry webUrl. The two links are for two situations and neither replaces the other: guiUrl opens GitWarren on the machine the user is sitting at, which is the right one when that is this machine; webUrl opens the same review in a browser from any of their devices - a phone, a laptop across the room - because it names this machine on their tailnet. Offer webUrl when the user is not at this machine, and both when you do not know.

Mark a discussion settled, or reopen one. Set resolved to true once the point has been addressed, false to bring it back. Resolving records who did it; it never deletes the messages, which stay readable.

Each result carries guiUrl, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by gitwarren serve or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one that works.

When this machine is reachable on the user's tailnet, results also carry webUrl. The two links are for two situations and neither replaces the other: guiUrl opens GitWarren on the machine the user is sitting at, which is the right one when that is this machine; webUrl opens the same review in a browser from any of their devices - a phone, a laptop across the room - because it names this machine on their tailnet. Offer webUrl when the user is not at this machine, and both when you do not know.

Replace the text of one message. An agent can only edit messages written by its own tool - correcting yourself is expected, rewriting someone else's review is not.

Each result carries guiUrl, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by gitwarren serve or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one that works.

When this machine is reachable on the user's tailnet, results also carry webUrl. The two links are for two situations and neither replaces the other: guiUrl opens GitWarren on the machine the user is sitting at, which is the right one when that is this machine; webUrl opens the same review in a browser from any of their devices - a phone, a laptop across the room - because it names this machine on their tailnet. Offer webUrl when the user is not at this machine, and both when you do not know.

Delete one message. If it was the only message in its thread, the thread goes with it. As with editing, an agent can only delete messages written by its own tool.