How to take control back from the AI

Automation is fun until you want to step in. ShipifyAI is designed so that a human can take back control of a pull request, a task, or an entire project at any time, without fighting the worker, without stopping the CLI, and without race conditions between you and the AI. This article walks through every path of taking control back, from one specific pull request, through one specific Jira task, all the way up to disabling automation for the whole project.

The philosophy that makes this work

ShipifyAI follows two simple rules that make hand-off effortless. The first rule is that the AI only picks up tasks from one specific Jira column, the source column configured in the project form. Anything outside that column is invisible to the AI. The second rule is that the AI only acts on pull requests whose title starts with the prefix `[AI GENERATED]`. Remove the prefix and the pull request becomes invisible to the AI.

You do not have to disable the worker to reclaim work. You just change the signals the AI reacts to. The worker keeps running, the integration stays connected, the heartbeat keeps flowing, and the specific work you want to take back simply falls outside the AI's view.

Taking back a specific pull request

Imagine the AI has opened a pull request titled `[AI GENERATED] feat: add password reset endpoint` and you want to finish the work yourself. The action is to edit the title and remove the `[AI GENERATED]` prefix. That is the entire procedure.

Under the hood, every iteration of the PR review follow-up loop asks the backend for open pull requests whose title starts with `[AI GENERATED]`. With the prefix removed the pull request no longer appears in the list. The AI will not reply to new comments on it, will not push additional commits to it, and will not add reactions to review threads. From that moment forward you can pull the branch, push your own commits, force-push if you have permission on the branch, and merge through the normal review process. The pull request is yours.

Be aware that putting the prefix back in the title puts the pull request back into the AI's view. That is occasionally useful when you want to ask the AI to address fresh review comments after your own changes have settled. Just remember the prefix is the switch.

Taking back a specific Jira task

Imagine you are looking at the board, you see the task `JIRA-241` sitting in Ready for Development, and you want to handle it yourself. The action is to move the task out of the source column. You can drag it into any other column, such as a personal "Picked up by me" column, the regular In Progress column with yourself as assignee, or even back to the backlog. The worker only fetches tasks from the source column, so as long as the task lives elsewhere, the AI will not touch it.

If you want preventive protection so that the AI cannot grab newly created tasks too quickly, configure the minimum wait time on the project. Setting it to one or two days means the AI will only pick tasks that have sat in the source column long enough for a human to claim them first. This gives every team member a window to take a task before the AI does.

If the AI has already started a task, you have two paths. The cleanest is to wait for the pull request and then remove the prefix from its title, taking the work over the moment it becomes visible on GitHub. The faster path is to move the task out of the source column or back to a different status. At the next loop iteration the worker notices the change and stops operating on the task. The feature branch and any work-in-progress remain on GitHub for you to pick up with a fetch and a checkout.

Pausing automation for an entire project

Sometimes you enter a release freeze, a refactor sprint, or a quiet period and you want the AI to do nothing on a project for a few days. The softest option is to clear the source column. Move every task into another column. The AI has nothing to pick up, so it does nothing. The heartbeat keeps flowing and billing keeps counting, but no work is generated.

A firmer option is to use the Pause automation toggle in the project settings on the dashboard. The backend stops returning tasks on the CLI tasks endpoint and tells the worker that the project is paused. The worker drops into idle mode and stops invoking Claude entirely. It no longer counts as an active instance for billing.

A harder option is to detach the Jira integration on the project settings page. Without Jira the worker has nothing to fetch and no automation can run. Reattaching the integration later requires re-entering the API token. The hardest option is to delete the project from ShipifyAI. Every integration and every CLI binding is removed. The repository on GitHub itself is untouched.

Stopping a worker that is actively running

If you have terminal access to the worker, the simplest action is to press Ctrl-C in the terminal running `ShipifyAI start`. The CLI gracefully revokes its session by calling DELETE /cli/auth/revoke, terminates the active Claude session with SIGTERM, and exits. If the worker was halfway through a pull request, the in-progress branch and any work-in-progress remain on GitHub. Nothing breaks.

If the worker runs on a remote machine, you stop it from the dashboard. Go to CLI Tokens, find the device entry, and click Revoke device. The backend invalidates the session token. On its next heartbeat or task fetch the worker receives a 401, logs the error, and shuts down. If you operate multiple workers, each one is a separate device entry that can be revoked individually.

Taking back a specific review thread on a pull request

Imagine the AI is replying to review comments on an `[AI GENERATED]` pull request and you want to take over one specific thread without disturbing the rest. The worker considers a thread actionable only when the most recent comment is from a human, the comment is at least six hours old, and the bot has not yet replied with `done`. Threads where the bot's last reply was `done [AI GENERATED]` are skipped automatically.

You can take a thread back in three ways. You can reply on the thread as a human. The AI treats your reply as a new state and waits another six hours, during which you can keep replying or resolve the thread to keep ownership. You can resolve the thread, because the AI does not act on resolved threads. Or you can remove the `[AI GENERATED]` prefix from the pull request title, taking back the entire pull request at once.

Emergency: stop the worker right now

If the AI is doing something you do not understand and you want it to stop, the control is local to the worker machine. Press `Ctrl+C` in the terminal where `ShipifyAI start` is running, or kill the process / container by whatever mechanism you use to manage it (`docker stop`, `systemctl stop`, `kill <pid>`). The worker exits cleanly between tasks; if it is mid-task, the in-flight Claude subprocess is terminated together with the parent.

To additionally invalidate the CLI session on the backend side so the same token cannot resume work from elsewhere, run `ShipifyAI logout` before (or after) stopping the worker. This calls `DELETE /cli/auth/revoke`, which marks the session as revoked server-side and clears the local credentials. The master CLI token itself remains valid and can mint a new session on next `ShipifyAI start` — to retire the token entirely, delete it from the CLI Tokens page in the dashboard.

After the worker is stopped, the only artefacts the AI has left in the outside world are feature branches on GitHub or GitLab, open pull/merge requests with the `[AI GENERATED]` prefix, and `[AI GENERATED]` comments on the task board. These are safe, frozen states. You can clean them up at your own pace, or leave them as a historical record. Nothing keeps running in the background.

There is no account-wide "off switch" in the dashboard, and we do not plan to add one. The deliberate design is that control over the worker lives on the machine that runs it: whoever has shell access to the worker can stop it, and whoever has dashboard access can revoke individual CLI tokens. If you operate multiple projects and need to stop them all at once, do it at the infrastructure layer (stop every worker container) rather than expecting a single button in ShipifyAI.

What the AI never does, so you never have to take it back

The hand-off model rests on bright lines. There are several actions the AI is structurally unable to take, which means you do not have to defend against them. The AI cannot push to the default branch. This is enforced by GitHub branch protection rules and by the scope of the GitHub PAT, as the security article explains in detail. The AI cannot revert a Jira task to an earlier state. Transitions are one-way through Ready, In Progress, In Review, or Incomplete. If you move a task back yourself, the AI will only consider it again when it lands in the source column. The AI cannot modify Jira directly. Every status change and every comment goes through the ShipifyAI backend, with a whitelist of allowed transitions and a forced `[AI GENERATED]` prefix on comments. The AI cannot delete branches, pull requests, or Slack channels. And the AI cannot read your secrets to other systems, because those secrets are not on the worker machine in the first place.

Frequently asked questions

People often ask whether the AI will overwrite a manual commit pushed onto an `[AI GENERATED]` branch. The answer is yes, the AI may rebase or push additional commits. The safer pattern is to remove the prefix from the title before pushing your own work, taking the branch over cleanly.

People ask what to do if the AI replied `done [AI GENERATED]` and they want to continue the discussion. Replying again on the thread is enough. After six hours the thread becomes actionable again, so you should either keep replying within six hours or remove the prefix from the pull request title to take ownership permanently.

People ask whether they can finish work the AI started. They can. Fetch the feature branch with `git fetch` and check it out, push your own commits, and either open a pull request without the `[AI GENERATED]` prefix if the AI has not opened one yet, or remove the prefix from the existing pull request title.

People ask why the heartbeat reports the worker as active even though no work is happening. The most common cause is that every task in the source column is younger than the configured minimum wait time. The worker is idling correctly until tasks become eligible. The heartbeat keeps flowing, but no Claude tokens are spent and no billable work is generated.

Where to go next

The security article explains the structural protections that ensure the AI cannot escape its sandbox. The Claude configuration article explains how to tune the worker so that it less often needs your intervention in the first place.