ConnectOnionAll Posts
Remote Browser

No Dialog Is Not Approval

Apply the same outside-workspace and unknown-tool policy when no approval UI exists; missing dialogs must not grant authority.

By ConnectOnion Team · 2 min read · 260 words

Remote BrowserPermissions

A headless co ai run was asked to write one canary outside its project. It started in Auto, had no browser or other approval channel, and wrote the file without asking. The same operation in O Chat was correctly classified as an outside-workspace write and denied. The permission mode had one name but two boundaries.

The split came from an old shortcut. The deterministic Auto policy only ran when agent.io existed, because its ask decisions were designed to open a dialog. Without IO, the older approval hook simply returned. That kept local library calls noninteractive, but it also meant that one-shot co ai skipped the path and effect checks that made Auto safe.

Treating every headless call as denied would have fixed the escape by making Auto unusable. Workspace reads, reversible workspace edits, and focused verification are the operations Auto is meant to perform unattended. The correct boundary is the policy decision itself: run the same classifier with or without a UI, preserve its allow and deny results, and turn only ask into deny when nobody can answer.

Full access remains separate. An operator can explicitly select its bounded turn grant for trusted unattended work, and protected control files still cannot be rewritten. A missing dialog is now the absence of consent, not an implicit grant.

The regression covers both sides of the boundary: headless Auto allows an inside-workspace edit, rejects outside reads and writes plus unknown tools, and bounded Full access retains its explicit bypass. Permission policy should not depend on whether the product happened to render a button.

Star us on GitHub

If ConnectOnion saves you time, a ⭐ goes a long way — and earns you a coffee chat with our founder.