Giving a coding agent write access

Giving a coding agent write access to a feature request board does not mean handing it a login or an API key into a live database. It means letting it change files in a repository, with every change sitting as a diff until a person reads and merges it. What that should cover, and what it should not, is a decision worth making deliberately.

This is one piece of a larger loop. For the whole thing end to end, see running support with a coding agent.

What does "write access" actually mean here?

A request board built as files in a repository has no separate database an agent could reach into. A new feature request is a file. A roadmap item is a file. A changelog entry is a file. Write access, in this setup, means the agent can create or edit those files and open a change against them, the same mechanism a human contributor would use.

That is a genuinely different shape from what write access means for a hosted tool's built-in AI, which usually holds an API key that can insert, update or delete a row in a live database directly, with no diff and nothing to read before it takes effect. A file the agent edits still has to pass through version control before anything downstream sees it. That gap, between a change being made and a change being live, is the whole point of doing it this way.

What should the scope actually include, and what should it leave out?

The honest way to scope this is to separate three tiers: what the agent can read, what it can propose changing, and what it can merge on its own.

Reading everything is cheap and low risk. Proposing a change, to a request's category, a draft reply, or a changelog line, is where the real value sits. Merging any of that without a person looking is the part worth being deliberate about withholding, at least at first.

Writing the scope down somewhere the agent actually reads, rather than leaving it as an unstated assumption, keeps the boundary on the page rather than in someone's memory of what was agreed. A folder's permissions are weaker than a server's: a repository checkout an agent has open is usually broader than the task actually needs, so the fence has to be drawn as a convention it is expected to follow, not a wall it structurally cannot get past.

Why does the review step matter more than the grant itself?

The permission scope gets most of the attention, but the review step is doing most of the actual work. Every change the agent makes sits as an unmerged diff, on a branch or as a pull request waiting on review, exactly like a change from a human contributor. Nothing reaches the live site because the agent wrote it. It reaches the live site because a person read the diff and merged it. That single fact matters more than whether the agent was scoped to three files or thirty: a narrow scope reviewed carelessly is riskier than a wide one reviewed properly. The support inbox as a git repository covers why this shape makes review the default state of a change, rather than a step someone has to remember to add.

How do you keep every change reversible?

Version control gives you this for free if you do not throw it away. Every merge is one commit. A commit that turns out to be wrong reverts in one command, and the file goes back to exactly what it said before, with the mistake preserved in the history rather than erased. That is a different guarantee from a hosted tool's undo button, which usually only covers the last action and only for as long as the vendor chose to keep it undoable.

What do agents characteristically get wrong with write access?

A few failure shapes are worth planning for, because none of them are specific to a request board. They are what happens whenever an agent gets write access to anything.

• The commit message says one thing, the diff does another. A reviewer who reads the summary and skims the diff can approve a change that does not match its own description.
• Two requests get merged because they share a word, not a problem. Matching text is exactly what an agent notices first, and matching text is not the same as matching intent. Deduplicating requests covers this failure in full, because it is the single most consequential thing triage can get wrong with total confidence.
• A request gets filed under the wrong category, stated with total confidence. Nothing in the tone of an agent's output tells a reviewer whether the categorisation was easy or a coin flip.
• A merge conflict resolves in the agent's favour by accident, when a reviewer clicks through a conflict screen too quickly.
• The scope creeps. An automation meant to touch one folder ends up reaching more of the filesystem than intended, because nobody audited exactly what a tool call could reach.

None of these require the agent to be malicious, or even wrong. They are ordinary review failures, the same ones that happen with a human-authored pull request, just easier to miss when the author never gets tired or defensive about being questioned.

How should the scope widen over time, if it should at all?

Start narrow: read everything, propose the low-stakes changes, merge nothing. Widen the propose list first, for the categories of change that turn out accurate on review, before ever touching what the agent is allowed to merge unattended. The commit history is what tells you whether to widen scope, not a general sense that things have gone well. A category with a clean run of accurate proposals is a candidate for lighter review. One with a string of corrections is not, whatever it felt like at the time.

Some categories are worth never widening, however clean the track record looks. Anything that sends something to a customer without review, an email, a notification, an automatic public reply, is a different risk from editing a file nobody has read yet. Editing a file is reversible. A sent message is not.

Frequently asked questions