Take-over & hand-back

Sometimes approving and steering isn't enough — you want the wheel. Take-over pauses a run and lets you pick up the agent's own session in a terminal or multiplexer pane and drive it directly; loopkeep's safety floor stays on the whole time. Hand-back returns the run to the agent to keep running, with your changes accounted for.

Taking over

Take-over pauses the run and continues the agent's own session — same conversation, same memory. The agent knows what it was doing and now also remembers what you discuss and change. You can talk to it, edit files in the run's worktree directly, or both. When loopkeep can drive a multiplexer, the session opens in a new pane — the same space and tab as attended runs, named after the run — otherwise it opens in your current terminal.

While you drive, loopkeep's policy gates step aside — the segment is yours and is audited as such (start and end markers, plus your changes as a checkpoint). The one gate that stays on is the built-in floor: loopkeep's own policy, config and state files stay protected no matter who's driving, and no policy layer can relax that. Everywhere else the floor asks you first, but there is nobody left to ask once you are the one at the keyboard, so for a take-over session it is handed to claude as a refusal instead.

Handing back

Hand-back commits your changes as a checkpoint (loopkeep: human take-over plus your summary), generates a diff summary, injects it into the run's context, and resumes the run. The agent continues with an accurate picture of what changed while you drove.

Non-git workspaces

Session continuation works anywhere. The diff summary and the take-over checkpoint need git, so in a plain folder hand-back resumes the run without them.

When to reach for it

Steering (lk approve --steer) is cheaper when a sentence of guidance is enough. Take-over earns its keep when the fix is easier to make than to describe — untangling a wrong turn by hand, then handing the loop back.

Ending an attended run

An attended run doesn't finish the moment the agent stops — when it stops, it's your turn. The run stays running and its pane stays open, waiting for you. Type, and the agent picks up where it left off, under the same supervision as before. Because that wait is your turn, its idle time doesn't count against the run's time budget, the same way time spent waiting for you to approve an action doesn't.

So a quiet agent no longer ends a run. Three things do:

• Tell the agent to end it, in chat. Ask claude to wrap up — "we're done, end the run" — and it ends the run with its end_run tool. The run is marked completed, keeping any deliverable it already emitted, and the session and its pane close. This is the only thing that closes the claude session: the agent calls end_run only when you ask it to end or finish, never on its own and never because it decides the task is done.
• Close the pane. Closing the terminal ends the run — completed if the agent had emitted a deliverable, otherwise interrupted and resumable (lk resume <run> continues the same session).
• Finish it from outside. lk finish <run>, or Finish on the run in the app, tells loopkeep to stop supervising and mark the run done — completed if it produced a deliverable, otherwise interrupted and resumable — while leaving the claude session and its terminal alive for you to read and close. This is a detach, not a kill: unlike lk abort <run>, which stops a run by closing its pane, finish never touches the terminal.

Idle timeout

By default an attended run waits for you indefinitely. attended.idle_timeout in config.yaml caps that wait: an attended run left with no agent step and no input from you for that long is ended — interrupted and resumable — and a note lands in your inbox. Any activity, yours or the agent's, resets the timer. It's off unless you set it, and a project can set its own value. See the daemon reference for the format and where each layer lives.