Let an AI agent update GitHub issues safely

Gitsu's desktop app enforces limits on writes made through the Gitsu MCP server. Every write on that path goes through the running app, which checks its write switch and accepts only the bundled MCP binary. An agent's other GitHub tools and credentials remain outside these controls. Gitsu MCP requires a paid Seat through Pro or Team and exists only in the desktop app; see pricing for the current plans.

How do I give an agent write access?

You do not have to. Agent writes are on from the moment Gitsu is installed. At every launch the app adds the gitsu entry, pointing to the gitsu-mcp executable, to the MCP configuration of each supported coding agent it finds on your Mac, with no setup step. An agent you install later is picked up at the next launch.

Settings, MCP server, lists those agents as Connected or Disconnected. Disconnecting one removes the Gitsu entry from that agent's configuration, and Gitsu does not add it back. Above the list is one switch, Agents can write to your boards, which is on by default. It refuses subsequent writes from all agents using Gitsu MCP when turned off. Reading still works, and other GitHub integrations are separate.

What stops an agent from writing more than it should?

Three checks, all in the desktop app rather than in the agent:

1. Only Gitsu's own MCP server may connect. When a process dials the app's local socket, the app reads the process's executable path from the operating system and refuses anything that is not the bundled gitsu-mcp binary.
2. One switch refuses subsequent Gitsu MCP writes. The app reads Agents can write to your boards on every write. With it off, subsequent calls on this path are refused with "Agent writes are turned off in Gitsu → Settings → MCP server." Reads are not affected. The switch does not undo a write already accepted or revoke another integration's credentials.
3. The write list has no delete operation. The nine tools set a column, comment, add or remove labels, close, reopen, create an issue, and mark work started or finished. These tools can still make unwanted changes, so check the result. There is no delete tool, no tool that removes an item from a board, and no draft edit. The full list is on the MCP server page.

Each write answers only after GitHub accepts or refuses it. If the app quits mid-write, the agent is told the result is unknown and to re-read before trying again.

How do I see what an agent changed?

Gitsu writes as you, with your GitHub account, because it has no bot identity. So it marks agent work in three ways:

• A default mark on comments and new issues. Gitsu appends an HTML comment naming the agent and the date to comments and issue bodies written through its MCP server. GitHub hides HTML comments in the rendered page, so on GitHub the mark shows in the raw body. Gitsu reads it back into activity as a self-reported agent name. The MCP tools cannot turn the mark off.
• A status in the header. While a write is in flight, the top of the board shows "Claude Code is writing to this board", or the name of whichever agent is writing.
• The agent-working label. An agent can call start_work to put the agent-working label on an issue, which the board animates, and finish_work to remove it. If the agent process dies first, Gitsu removes the label itself.

A run started from the agent panel does not automatically add the working label to GitHub. An agent using Gitsu MCP calls start_work to add it; other tools can make their own label changes.

What does Gitsu not protect against?

These limits are recorded in Gitsu's design decisions, and they matter if you are deciding how far to trust an agent:

• The agent names are not proof. The app can prove the caller is the Gitsu MCP binary. It cannot prove which agent launched that binary, because the agent's name is claimed, not verified. The name in the mark and in the activity is what the agent said it was.
• Other GitHub access paths remain available. The write switch controls Gitsu MCP calls. It cannot stop an agent using gh, GitHub's MCP server or another credential to change the same repository. Restrict those paths separately when you need a read-only agent.
• There is no cap on how many writes an agent makes. Gitsu does not count or limit writes. What bounds an agent is the switch, the executable check, and the non-destructive tool list.
• There is no per-request confirmation. Gitsu asks nothing before a write. Your agent's host may ask before it runs a tool, in its own way.
• Disconnecting one agent is not instant. Disconnecting its row edits the configuration, but a session already running keeps the server until it restarts. Use the write switch to refuse subsequent Gitsu MCP writes without waiting for that restart. It does not cancel a write already accepted.
• Gitsu edits other apps' configuration files. It adds one gitsu entry to each supported agent's MCP configuration and leaves every other setting alone. Disconnecting the row removes it.

How does this compare with other trackers' MCP servers?

Compare the actual tools, permissions and host approvals configured for each server. Gitsu's distinctive constraint is its local write relay: its MCP writes need the desktop app running, use the app's write switch and can add default attribution to comments and new issues. This dependency also means the write path is available only on your Mac.

Do not treat installing Gitsu as a replacement for reviewing the agent's other integrations. A read-only configuration for another server and a disabled Gitsu write switch are separate controls. The Claude Code connection guide distinguishes GitHub's server from Gitsu's server and explains when each is useful.

Who is this for?

Developers and small teams who want a coding agent to update the board as it works, and who keep their work in GitHub Issues. Nobody else on the team has to install anything: the agent's changes appear on GitHub like any other edit. The getting started guide covers signing in and choosing boards.