Main idea

Driving Codex from a phone by connecting to the Mac that runs it solves the apparent problem — you work without sitting in front of the machine — and leaves three others untouched: the Mac has to be powered on, it has to stay connected, and remote access has to work. The mobility obtained is a conditional mobility, and its conditions sit several hundred kilometres away, with nobody around to restore them.

At home, the difference doesn't show: the three conditions are nearly always met, and remote access passes for a solution. It only reveals itself on a long trip, where the failure cannot be recovered and the working day is lost.

So the only way to lift the dependency was not to access the machine better, but to take it out of the equation.

Why it matters

This gives a way of reading remote access solutions in general: they convert a presence constraint into an availability constraint. That is a good trade when availability is administered by someone — a server, a service — and a bad trade when it rests on a personal device nobody is watching.

And it avoids a frequent misdiagnosis: believing you have solved an autonomy problem because you have solved an access problem.

Nuances and limits

Removing the machine has a price: the system that replaces it is slower and cannot run scripts. Lifting a dependency rarely trades against nothing.

And the demonstration only holds for a personal machine. The same architecture hosted on an administered service holds the three conditions by contract, and remote access becomes a legitimate answer again.

Open questions

• How do you estimate, before leaving, the probability that one of the three conditions fails while you are away, given that none of them is instrumented?