A guardrail becomes difficult to keep enabled when every interruption sends you looking for a phone or typing another code. I've experienced that friction using coding agents, and I've been working on the ways Doberman asks for a decision and helps you recover afterward.
There are several changes worth trying together. They solve different parts of the workflow, so it helps to know where each one applies.
On a Windows laptop, Windows Hello can supply the proof for a supported two-factor action challenge. Once the method is available and enabled, the device verification flow can replace entering a TOTP code. The approval is still tied to the action in front of you. Hello doesn't replace every password or recovery gate in Doberman.
When you're away from the laptop, ntfy can bring the pending action to your phone with Approve and Deny buttons. On supported action challenges, a tap can provide the confirmation or second factor. It covers Claude Code and Codex hooks, Cursor hooks and the MCP proxy; OpenClaw uses its own approval flow. The notification goes through the ntfy server you configure, so the setup guide explains the data that leaves the machine and the self-hosting option.
Preference order matters when both methods are enabled. An available Hello method ahead of ntfy can handle a two-factor challenge before the phone is used. Checking the selected method is part of setting this up, rather than assuming every installed feature is active.
For eligible repeats, approval memory remembers the exact action for five minutes after a qualifying proof. A repeat can use a shorter confirmation. It still asks, and clicking again doesn't extend the original window. Changed arguments, targets or security context can require fresh proof. Destructive and other high-risk cases are excluded. There is also an explicit recovery route for sticky taint. After reviewing the situation, you can run doberman taint clear from your own terminal and verify with TOTP if enrolled, otherwise your Doberman password. It clears the repo's taint state across sessions without requiring an agent restart. A later sensitive read can taint it again. Hello and ntfy currently do not replace that recovery command's factor gate.
If prompts still get in the way, doberman tune reports the AUTH reasons and approval history. It can propose a narrow grant for qualifying repeated role-boundary cases, but the report applies nothing automatically. Any acceptance follows the human verification path. These features are released capabilities. Whether they make a particular workflow comfortable needs a real session on the relevant host, including ordinary work and the actions that used to cause trouble. I would measure time spent answering, repeated proofs, recovery effort and whether you choose to leave protection enabled.
Doberman is my open-source project. Which part of that workflow would make the biggest difference for you: approving locally, approving remotely, recovering from a flagged session, or understanding why a prompt appeared?