A job started on your Mac can be moved to another machine while it is running, and carry on.

This is the most unusual thing in the product, and the thing people do not believe until they watch it happen.

Why you would

• You started something on the laptop and now you are leaving.
• It turned out to be heavier than you thought and the Linux box is idle.
• You want the Mac quiet.
• The work needs to be near data that lives somewhere else.

What moves

The whole case. The files, the git history, the run history, and the conversation the agent was having. The worker keeps its identity, so the session on your phone does not fork into two.

The agent picks up where it left off, including things you told it only in chat. A constraint you mentioned on the Mac still applies after the job is on the Linux box.

Doing it

Open a running session, choose to move it, and pick the target machine from the ones you have connected. The phone shows the steps as they happen.

If the target has never run a job before, it prepares itself first: it builds the image it needs, on that machine, from the same recipe your Mac uses. That takes a few minutes once. Operator ships no image bytes, so what travels is the recipe, not a multi gigabyte layer.

The move sheet tells you the cost before you commit, so a first move to a fresh box is a decision you make knowingly rather than a spinner you sit through.

What gets left behind

The move sheet lists this explicitly, per item. Most things travel. A couple do not, and it says which, rather than letting you find out.

When it will refuse

• The target is unreachable.
• The target has no container runtime.
• There is not enough disk on the target to build what it needs.

In each case it says which one, and the job keeps running where it is. A refused move never leaves a job in between machines.

Moving back

The same way. There is nothing special about the direction, and a job can move more than once.