Timeouts and offline fallback

Manual approval timeouts and offline fallback handle different failures. Changing the offline choice does not change the response timer.

Manual approval timeout

When a policy result is Ask, Agent Approve waits up to five minutes for your decision. By default, if no decision arrives, the request is denied. That is the safest behavior for a request that already reached Agent Approve but did not receive a human answer.

A request that reaches its timeout is removed from the Approvals list on iPhone and Apple Watch automatically, so you cannot act on a request the service has stopped waiting for. The outcome remains in the event history.

The active policy controls how often this wait occurs:

• Default, the policy new accounts start on, uses Ask behavior with a populated Allow List and Deny List. Common safe commands are approved and clearly destructive ones are denied without waiting for you; everything else waits.
• Add safe, recurring actions to the Allow List so they no longer interrupt you.
• Use Restrictive, Permissive, or a custom policy when a different balance fits the computer's workload.

Auto-approve after a veto window

A policy can approve an unanswered request instead of denying it. On the Policy page, open On Approval Timeout and choose Auto-approve after veto window, then pick the window: 30 seconds, 1 minute, 2 minutes, or 5 minutes. The request stays on your devices for the whole window, so you can still deny it; if the window passes with no decision, the request is approved and recorded as auto-approved on veto expiry.

This setting trades safety for flow, so several rules always apply:

• A Deny List match is denied immediately. It never reaches the veto window.
• Commands classified as system-destroying, such as formatting a disk or removing the filesystem root or your home directory, are never auto-approved. They fall back to deny on timeout even when the policy opts in.
• Questions from the agent always wait for a real answer. An unanswered question is never auto-approved.
• A dropped connection during the window counts as a deny, never an approval.

The built-in safety floor covers global destruction only. An ordinary risky command that you care about must be in your Deny List, which always wins. Review the active policy's Deny List before enabling a veto window for unattended work.

All approval waits, including the veto window and the default deny wait, are capped at five minutes so a decision always reaches the waiting agent before it gives up.

Offline fallback

Offline fallback applies when the local integration cannot reach the Agent Approve API service. It does not start after a request has already reached your phone, and it does not change the manual approval timeout.

Choose an offline behavior based on what should happen when no remote decision is possible. An allow fallback can keep unattended work moving, but it also lets work continue while the approval service is unavailable. Review the safety consequence before enabling it.

Rerun npx agentapprove install to change this computer's offline choice. It is stored as AGENTAPPROVE_FAIL_BEHAVIOR in the managed computer configuration.

Avoid a common mistake

Offline fallback is not a policy default. If you want unmatched commands to come to you for review, choose a policy whose default behavior is Ask. Keep push notifications enabled, then add safe recurring actions to the Allow List as you learn what should proceed automatically.

Voice Follow-up uses a separate timer

Voice Follow-up begins after a supported agent finishes a turn. Its hook can wait up to five minutes for another instruction. If the prompt expires, no message is sent and the waiting hook is released. Nothing is approved or denied because the agent has already finished the turn.

See Voice Follow-up if the native agent appears busy or delays your next prompt while this wait is active.