An approval card is only useful if you can tell what you are approving. A card that says "Run a command?" and shows a shortened version of it asks you to click on trust. BeyDock's approval cards follow one rule: the card shows everything the click will approve, and "Allow" never approves more than what is shown.
The full command, as the agent reported it
When an agent wants to run a shell command, the card shows the command the way the agent announced it. We do not tidy it up. Simplifying a command, such as trimming a shell wrapper, happens only in the transcript, after the fact. On the card, a shortened command is a way to hide something, so it stays as is.
Every file, with its diff
A single approval can change several files. Codex, for example, applies a whole patch with one approval. In that case the card says "Make edits to 3 files?" and lists each file with its diff. A single Edit shows its diff. A new file shows its content.
The detail that matters is where that list comes from. The input of a tool call is written by the model. If the card built its file list from that input, a model could show you one change and request another. So the list of files travels in a separate field of the permission request, permission_request.files. In the Codex provider, the sidecar fills it from the change items it received from the Codex app server. The card reads that field first and does not take the file list from the tool input. The model never writes what the card displays.
The same rule on every approval
The principle carries over to the other places where a card appears:
- Starting a child agent (Delegation): by default BeyDock asks before starting a child that edits files, and Settings › Agents can make it ask for every child or never. The card shows the whole task text, the target (provider, account, model and effort), the access level and the workspace. A child's permission requests are mirrored into the parent session, headed with where they came from: title, provider and account. Answering either copy closes both.
- Applying a child's changes:
agents_applyshows every file with its diff, and applies exactly the tree you saw. If the child started running again while the card was open, nothing is applied. - Hub tools: when the Hub asks, the card shows the input as the model sent it, the connection (which identity the call will use) and the host. "Always allow" says its scope on the card: this tool, this consumer, this connection.
- Workflow approvals: the card shows the resolved action, such as "push this branch (14 commits) to dev". The approval is tied to that preview, so if the branch moved afterward, nothing is pushed and you are asked again.
If a request carries no durable rule, the card has no "Always allow" button. A button that does the same as a single Allow would only be noise.
Providers ask differently
Each provider has its own permission model, and the card hides the differences. Claude asks through the SDK's permission callback. Codex sends approval requests with its own decision lists. OpenCode sends ACP permission requests. Antigravity cannot ask in the middle of a turn at all. Its permission mode decides up front what it may do, and a tool it was not allowed to use shows in the transcript as denied. For Delegation, BeyDock makes the decision in the sidecar, so even an Antigravity session gets a card before it starts a child, and no provider asks a second time.
Links and local files
Anything an agent, an MCP server or a plugin writes into the transcript is untrusted, including links. Only web addresses (http and https) are opened. A file:// link is never opened. If the file exists, it is revealed in Finder, so clicking a link cannot launch a .command file or an .app. Links with other schemes, such as ones that trigger another app, are ignored. Actions on local files, like Finder reveals, apply to local sessions only. On an SSH host, the file is not on your Mac.
The same habit shows up in Delegation: a child's result is wrapped in an <agent_result> block and the parent is told it is data, not instructions. In Workflows, text from pull requests and CI logs is marked <untrusted> when it enters a prompt.
Why we are strict about this
Agents are getting more capable, and they are doing more work while you are not looking. The approval card is the one place where you are still in the loop. We would rather have a card that is a little long than one you cannot trust. These are rules we hold every new feature to, and they are written into the project's own guidelines.