You ask an agent to investigate a failing test. Reading the test and running a harmless inspection command are ordinary parts of that work. Changing the implementation, applying a specialist's patch or running a command with wider consequences may need your approval. The useful boundary is the action that reaches your files and terminal.
A product that coordinates several agents has to carry that boundary through several routes. Claude Code and Codex have their own execution paths. Skyflo's own agent reaches commands and files through its tools. A specialist may produce work that the lead later applies. The person should be able to choose a mission's access once and see that choice respected wherever its work lands.
Desktop 1.5.1 brings Skyflo's own agent onto those shared command and file approval rules. In Ask for approval, a command or file change that needs permission stops at an explicit request. Auto-accept edits permits edits and keeps the command approval boundary. Plain inspection commands, such as listing files or reading Git status, remain available without interrupting the person. The request shows the work being proposed, and a paired phone can answer it when the Mac is connected.
Permission Has to Survive the Route
An instruction in a conversation describes what the person wants. The execution path still has to decide whether a proposed action fits the mission's current access. That decision belongs where the command runs or the file changes. Otherwise two agents can understand the same instruction and behave differently simply because they reach the workspace through different tools.
This becomes especially visible when a lead applies a specialist's work. The specialist can prepare a patch within its task. Applying that patch is an action of the receiving mission, and it has to respect that mission's approval policy. A completed specialist report does not grant permission to change the lead's workspace.
The earlier essay, An Approval You Can Read, describes why an approval should show its consequence clearly. This release closes another part of the same workflow: the built-in agent must reach that readable request when it proposes an action that needs one.
Another Mission Keeps Its Own Identity
In A Message Is Not the Person, we described missions asking each other questions without somebody copying messages between windows. That channel is useful because the receiving mission already has a workspace, an agent and a record of its work.
A message keeps those boundaries. It is attributed to the mission that sent it and runs under the receiving mission's own agent, model and access. It cannot approve a pending action for the person or increase what the recipient may do. In 1.5.1, discovery and delivery stay within the same workspace. A mission cannot use a message to hand work to one with more authority than its own.
The release also fixes the built-in agent's continuation after delivery. In 1.5.0 the message could arrive and still leave the sender's turn with a connection error. Delivery and the sender finishing its own work are separate outcomes. The sender now keeps working after its message has been sent, and a reply comes back through the receiving mission's ordinary message path.
Keep the Person's Choice Visible
These changes preserve the coding agents people already run on their Macs, including Claude Code. They also preserve the distinction between a person authorizing work and an agent proposing the next step. The mission's access setting, the exact approval request and the attributed message each explain a different part of that decision.
Commercial Skyflo Cloud execution remains disabled. The changes described here apply to the released Mac workflow; this release does not activate commercial Cloud or a new provider arrangement.
The Desktop 1.5.1 release notes record the changes, including the managed-model capacity and continuation fixes. The control plane's job is to carry your chosen authority all the way to the work and keep the result available to inspect.