Contents
Getting started
Using Codepanion
Connecting your tools
Reading your code, querying your database, searching your logs and your wiki: all of it is read-only, and all of it happens without asking. Two tools are different. They act on a system outside Codepanion, where the result is visible to other people and can't be quietly undone. Those two never fire on their own.
What needs approval
create_issueFiles a new issue in a connected issue tracker.propose_changeTurns a fix into a patch and, on GitHub, attaches it to an issue and opens a draft pull request for a one-line change.
When the agent calls either of them, the turn suspends. Nothing is sent while it waits. An approval card appears in the thread where the tool step would have been, and the rest of the answer doesn't continue until you decide.
Before drafting an issue the agent may ask your tracker for its recent issues to match your house style: titles, labels, the shape of a good report. That only reads, so it isn't gated and you won't see a card for it.
What you're shown
The card is a preview of exactly what will be sent, field for field, with nothing summarised or paraphrased. What you read is the payload.
If Codepanion can't build that faithful preview, it doesn't execute. You would be approving something you can't see, so the action is abandoned and the agent is told it wasn't taken. That is the safe direction to fail in.
Approving and declining
Approve runs the action with the same arguments you were shown. The preview and the request are built from one set of values, so what you read is what goes out. The turn then carries on and the result appears as an ordinary tool step.
Decline tells the agent to continue without taking the action. It usually explains what it would have filed so you can decide for yourself. Leaving the card alone has the same effect: after up to five minutes with no decision the action is treated as declined and is not taken. The wait is bounded by the turn's own deadline, so a card raised late in a long turn expires sooner, and a second card in the same turn gets whatever time is left.
Note
Approval needs the live connection an investigation holds open while a turn runs. If a turn can't stream, the write tools are unavailable for it entirely: the agent is told the action was not taken rather than being allowed to take it unattended.
Proposed code changes
propose_change is deliberately modest about what it will do on your behalf. It always produces a unified-diff patch with a title and a short rationale. On GitHub it attaches the patch as a comment on the issue you point it at. On Jira, Linear and Salesforce nothing is written to the tracker: the patch text is handed back in the thread for you to relay.
It opens a pull request only when both conditions hold: the provider is GitHub, and the change is a true one-liner, a single changed line. That PR is opened as a draft. Anything longer, and any other provider, is patch-only. Codepanion never merges anything.
Which providers can be written to at all is set by the integration: Jira, Linear and GitHub accept new issues; Salesforce is read-only, so the write tools never list it and the agent cannot ask you to approve a write there. See integrations.
The record
Every decision is written to the audit log against the investigation it belongs to: which tool, what was previewed, whether it was approved or declined, and who decided. The row names the person who clicked, who on a shared investigation is often someone other than the person who asked the question; a card that expired is recorded against the actor system, because nobody decided. A decline is recorded as deliberately as an approval, so "why didn't this get filed?" has an answer.