Making agent approvals easier to live with

Guardrails can become cumbersome when interruptions require searching for a phone or entering additional codes. The author has encountered this friction while using coding agents and is exploring ways to ease the Doberman authentication process. Several modifications can be applied, each addressing a different aspect of the workflow. It is beneficial to understand the specific situations in which each improvement is applicable.

On a Windows laptop, Windows Hello can provide proof for a two-factor authentication challenge. When this method is enabled, the device verification flow can take the place of entering a one-time password (TOTP) code. However, the approval remains linked to the specific action at hand and does not replace every password or recovery gate within Doberman.

For instances when the user is away from their laptop, the ntfy system can bring the pending action to the user's phone with "Approve" and "Deny" buttons. A tap on supported action challenges can serve as confirmation or provide the necessary second factor. This applies to Claude Code and Codex hooks, Cursor hooks, and the MCP proxy. OpenClaw utilizes its own approval flow.

The notification process is handled through the ntfy server that the user sets up, which means it is important to review the data that is transmitted and the self-hosting option. Approval preference order is crucial when both methods are enabled. When a Windows Hello method is available before ntfy, it can manage a two-factor challenge before the phone is used. It is essential to verify which method is selected, rather than presuming all features are active.

For eligible repeated actions, approval memory stores the exact action for five minutes following a qualifying proof. A repeat can utilize a shorter confirmation, but clicking again does not extend the original window. Modified arguments, targets, or security context may necessitate fresh proof. High-risk cases and destructive actions are excluded from this process.

There is an explicit recovery route for "sticky taint." After examining the situation, the user can execute "doberman taint clear" from their terminal and verify with a TOTP if enrolled, or their Doberman password otherwise. This clears the repository's taint state across sessions without requiring an agent restart. A subsequent sensitive read can once again taint the repository.

Windows Hello and ntfy currently do not replace the recovery command's factor gate. If prompts remain an issue, "doberman tune" reports the AUTH reasons and approval history, proposing a narrow grant for qualifying repeated role-boundary cases. However, the report does not implement changes automatically.

Any acceptance follows the human verification path. These features are released capabilities, and their effectiveness in improving a specific workflow should be evaluated through real-world use on the relevant host, including routine operations and actions that previously caused difficulties. The author encourages measuring the time spent approving, repeated proofs, recovery effort, and whether protection remains enabled.

Ultimately, the decision on which aspect of the workflow would have the most significant impact is left to the user, as Doberman is an open-source project and the author welcomes feedback on which part of the process would make the biggest difference.