Fixing issues from your machine

An issue in Parsemend already carries what a debugging session needs: the exception and its stack frames, the events around it, the breadcrumbs leading in, other errors sharing the same trace, and the logs from that request. The @parsemend/cli package hands that bundle to whatever is doing the fixing on your machine.

There are two ways to spend it, and they differ in who drives.

Your agent session drives

You already have a session open — Claude Code, Codex, or another MCP client — with a model you chose and tools that read and edit your repository. Register Parsemend as an MCP server and that session gains four tools: list the issues, pull one issue's context, optionally run Parsemend's own analysis, and publish what you changed.

npm install -g @parsemend/cli
parsemend login
claude mcp add parsemend -- parsemend mcp

Then, in the session:

> fix postlyra-12

No provider API key is needed for this path. The session's model does the reasoning, so /model is what picks it. Start at Claude Code, Codex and other MCP clients.

The CLI drives

No session, one command. parsemend fix runs the same root-cause → plan → coding pipeline itself, against your working copy, using your own provider key.

parsemend fix postlyra-12

This is the right shape for a scripted or headless run, and the wrong one for a fix you want to steer, because its coding step is a one-shot subprocess that cannot ask you anything. See parsemend fix.

What leaves your machine

Both paths read your source locally and neither uploads it. Parsemend serves the context bundle; your machine does the rest. The single outbound call is post_back, which is opt-in and sends a git diff plus any analysis already run — never whole files, and never a repository.

That is also the honest cost of working this way: unless you call post_back, Parsemend never learns that the issue was worked on at all. The issue shows no run and no timeline. Source that never leaves cannot be reported on.

How this differs from the agent

The agent in the panel works the other way round. It clones the repository into Parsemend's own workspace, runs the same pipeline there, and opens a draft pull request against the failure. It never merges.

Neither local path opens a pull request. post_back records a fix run on the issue; committing, pushing and opening a PR stay yours.

Before you start

• Node 20 or later.
• A Parsemend account, and an issue with at least one event.
• A git repository — post_back reads the working tree through git.

Next: install and sign in.