Face ID for a Word
On September 26 we ran the loop the 1.3 essay promised we would run before the phone app goes to Apple: a real iPhone, paired to a Mac, against production. A mission had Claude Code working in a repository. It stopped to ask for permission, the phone lit up, and the approval said Bash, then asked for Face ID.
Everything underneath was working. The decision was signed on the phone with a key that never leaves it, the Mac checked the signature before acting, and the approval was bound to that one request, so the agent could not have swapped in a different command afterwards. None of it helped, because the person holding the phone could not see the command. They were being asked to authorize a word.
Binding Is Not Seeing
The 1.3 essay argued that the phone decides and the Mac acts, and that a decision is worth something only when it is bound to the exact action. That is still the design. For an action Skyflo prepares, the binding covers the operation, its inputs and its target. For a permission request from Claude Code or ChatGPT Codex, the binding is that agent's request: if it asks again with anything different, that is a new request, and an answer to the old one is refused as stale.
Binding solves half of the problem. It guarantees that what runs is what you approved. It says nothing about whether what you approved was something you could read. A precise signature over an opaque label is a well-authenticated guess. A strong confirmation on an unreadable request may be worse than none, because it teaches the person that confirming is a formality.
The Mac app never had this problem, because its approval card sits beside the tool call it is about, and the tool call carries its inputs. The phone's approval was built from the gate itself, which names only the tool and the kind of thing it touches. The substance lived one record away.
What the Phone Shows Now
In 1.4.3 the Mac reads the same record the Desktop draws its tool card from and sends the substance with the approval. A command arrives as the exact command. A file change arrives as the file and what would happen to it: edit, create or replace, with every file listed when one change touches several. And every approval says who is asking, in a sentence: Claude Code wants to edit src/cart.ts.
Claude Code calls its shell tool Bash, and Codex has its own names for the same operations. A phone should not have to learn those vocabularies, so the Mac translates them once, and names like file_write no longer reach the screen. Face ID is still asked for on a risky command. It is now asked for underneath the command it protects.
The Lock Screen Has Other Readers
A notification is an approval's first appearance, and it is read by a wider audience: anyone who can see the phone on the table. So the plain sentence has two forms. At full detail, the notification names what the agent wants to touch: Claude Code wants to edit src/cart.ts. When you choose to show only the mission and the reason, it leaves the target out: Claude Code wants to edit a file. Neither form shows a raw tool name, which told nobody anything at any level.
The Context Around a Decision
The action is the center of a decision, not all of it, and the phone misreported the rest too. The conversation now shows your own answers and guidance in order, with what happened to each piece of guidance, so you can see whether what you sent was taken. A turn that is waiting for you reads as waiting, not working. Agents are named as themselves, Claude Code or ChatGPT Codex, rather than all as Skyflo. And mission times are when the mission last changed. Before, every row said 1h ago, because the phone was showing when the Mac last sent the list.
Pairing got the same treatment. When Skyflo's Terms have changed, the Mac's pairing dialog checks as it opens, says so, links to the new Terms, and offers Agree and approve, which records your agreement and pairs the phone in one step. Before, pairing stopped at an error code with no way forward. Every refusal in that dialog is now a plain sentence with the next step.
Why the Loop Runs on a Real Phone
Our automated checks asked whether approvals were signed, bound and checked by the Mac, and they were. It took a person holding a phone, being asked for their face, to notice that the question was blank. That is why the whole loop runs on real phones against production before the app goes to review: the property that matters most to the person deciding is the one a test is least likely to state.
Skyflo for iPhone and iPad is still in testing and reaches the App Store after Apple's review. The Mac side of these changes is in Skyflo 1.4.3, alongside a fix that lets missions on your plan's included models wait for capacity instead of failing. The 1.4.3 release notes list everything.
The rule from 1.3 stands: the phone decides, and the Mac acts. This release adds the condition that makes the first half mean something. A decision needs something to decide about.