Before your AI agent edits Linear, test how you will recover

Stanislav Sysoiev — Sat, 14 Nov 2026 20:19:28 +0000

“Clean up the backlog” sounds like a small task until you have to define clean.

Does an issue with no updates for six months need closing? What if it describes a security problem? Are two similar titles duplicates if they affect different customers? Can an agent shorten a description without dropping the one reproduction step that matters?

Imagine an agent closes 40 issues and rewrites 12 descriptions. Some changes are useful. Others are wrong. Meanwhile, a teammate adds a comment and updates an assignee.

Now you need to recover the wrong changes while keeping the useful ones and your teammate's work.

That's a hypothetical example, but it's the question I would answer before enabling bulk edits. I build BackupLatte, a backup service for Linear and ClickUp, so my interest here is also practical: what can you actually recover after a tool has changed your data?

Start with a proposal you can inspect

For a first run, give the agent a task that ends with a proposed change list:

Review open issues in the ENG team that have not been updated
in the last 180 days. Do not modify anything.

For each candidate, show:
- the issue identifier and URL
- its current status
- the proposed status
- the evidence for making that change
- anything that makes the decision uncertain

Exclude issues in active projects and issues with unresolved
dependencies. List possible duplicates separately; do not merge
or delete them. Return at most 10 candidates, then stop.

The exact rules should come from your team. The useful part is that you can inspect individual decisions before they become writes.

For that initial review, enforce read-only access in the connection. Linear offers an MCP endpoint at https://mcp.linear.app/mcp/readonly that exposes only read tools. Its standard endpoint can also be used with only the read OAuth scope. Linear's MCP documentation describes both options.

A sentence saying “do not modify anything” helps communicate intent. A read-only connection also prevents a write if the agent gets that instruction wrong. Check for other connected tools or credentials that could still give it write access.

When you enable writes, keep the permissions narrow. Linear personal API keys can be restricted by permission and team. For an OAuth integration that only posts comments, comments:create is available instead of broad write access. These are different connection mechanisms; check the one your agent actually uses. API keys · OAuth scopes

Approve specific changes, then check that they are still current

“Those suggestions look good” is a weak handoff if the next run searches the backlog again and generates a different list.

Keep a record of the approved operations. For a status change, it could look like this illustrative record:

{
  "issue": "ENG-142",
  "field": "status",
  "before": "Backlog",
  "after": "Canceled",
  "reason": "Superseded by ENG-201; confirmed by the owner"
}

This is a review record, not a Linear API request. An executor would resolve and use the actual issue and workflow-state IDs.

Before applying it, read the issue again. If its relevant fields have changed since approval, skip it and ask for another review. A preflight read reduces the chance of overwriting newer work, although it cannot eliminate a race between that read and the write.

If you control the integration, enforce the approved issue list, permitted fields, and batch size in code. If you only control an agent prompt, treat those limits as instructions whose enforcement you still need to verify.

Start with a small batch. Save the old values, the attempted operations, and their outcomes somewhere the editing agent cannot modify. A list of successful requests alone won't tell you what to put back.

Rehearse recovery in a separate workspace

Before trying a bulk cleanup on the live backlog, make a disposable test workspace with a few representative issues. Use synthetic or sanitized content if real tickets contain sensitive information.

Include cases where a simple rule should fail: an old but important issue, two similar titles that aren't duplicates, a parent with an unresolved sub-issue, and a description containing an essential attachment.

Then run a small recovery exercise:

Save the starting state and confirm you can read it back.
Run the agent's proposed task against the test workspace.
Add a legitimate human edit after the run.
Recover a wrong status change, an overwritten description, and a deleted test issue using the recovery methods you intend to rely on.
Check that the legitimate edit and relevant relationships or files survived.

Record how long this takes and which steps need a person. If you are testing a restored copy of real data, check what your restore tool actually carries over; a copy may have different identifiers, users, permissions, or missing features.

The point of this exercise is to discover those differences while nobody is waiting for their backlog to work again.

Recovery depends on what changed

Once you discover a bad run, stop further writes first. Revoke the relevant credential or integration authorization, and stop the running automation. Disconnecting a client is only sufficient if that actually removes its ability to keep writing.

Then separate the damage:

What happened	What to check before repairing it
Statuses, labels, or assignees changed	Compare saved values with current values. Preserve any legitimate edits made afterward.
Descriptions were overwritten	Retrieve the earlier text and merge back the missing content.
Issues were deleted	Check Linear's Recently deleted items first.
Unwanted issues or comments were created	Identify the specific new records and review their removal.

Linear retains recently deleted issues for 30 days, and its documentation describes restoring them from the team's archives. That gives you a recovery path for deletion; it doesn't undo unrelated field edits or identify unwanted new records. Linear's deletion and recovery documentation

This distinction matters when choosing a backup tool, too. Ask what its Restore button does to an existing record whose description has changed.

In BackupLatte, restoring into the original Linear workspace recovers supported missing records and reuses matching existing ones. It does not overwrite existing records to roll back their fields. For overwritten text, you can consult a downloaded snapshot or a copy restored into another workspace, then bring back what you need. The restore guide explains the behavior and limitations.

A snapshot also has to predate the mistake and remain available when you discover it. Check its timestamp, coverage, and retention before a consequential run.

The question to answer before the first write

Pick one proposed change and ask:

If this is wrong, where is the previous value, who can recover it, and how will we preserve work done afterward?

If you can demonstrate the answer in a test workspace, you have a concrete basis for letting the agent make a small batch of real changes.