Skip to content

Notify only when the sign-in actually needs you - #90

Merged
popen2 merged 1 commit into
mainfrom
claude/frost-auto-approve-e2e-suite
Sep 14, 2026
Merged

popen2 merged 1 commit into
mainfrom
claude/frost-auto-approve-e2e-suite

Conversation

@popen2

@popen2 popen2 commented Aug 31, 2026

Copy link
Copy Markdown
Owner

This is the auto-approve (behaviour) PR. Stacked on #89, which is the testing one — base is that branch, so this diff is only the behaviour change and the two scenarios that prove it. GitHub retargets it to main when #89 merges.

Rebased onto main at 7522d2e (after #92).

The problem

Notify mode is a promise not to put a login page in front of you unannounced, and it kept that promise by announcing every refresh: notification, wait for the hotkey, then the login window. With automatic approval that is backwards — most refreshes now ask you for nothing, so notify mode was interrupting you once a working day about work Frost was about to do silently.

The change

The notification moves to the moment a refresh turns out to need a person. Frost works through the approval off screen; if the page asks for a password, a one-time code or a security key, notify mode says so and waits for the hotkey or a click before showing anything. A refresh your identity provider session covers passes in silence.

With automatic approval off, nothing changes — a login page is still about to open, so it is still announced first.

It composes with #92

canRefreshUnattended() excluded notify mode because the old flow waited for a hotkey nobody was there to press, so an unattended notify refresh stopped before even asking AWS for a device code. The new flow only waits when the page actually needs a person, so that exclusion is now wrong: an overnight refresh in notify mode renews credentials like any other. That is one line plus its comment, and it is why this PR touches canRefreshUnattended().

The hand-over still respects #92's parking: nobody at the machine means the login is held hidden and nothing is said — you do not notify an empty room. The notification is for a person who is actually there.

Two details that go with it: the pending trigger is cancelled when the run ends (otherwise hasPendingAuth() keeps saying yes and swallows your next hotkey press), and a refresh you ask for while the notice is unanswered counts as saying yes, so it reaches the page Frost is already holding rather than "a refresh is already running".

Tests

Two scenarios in the suite change hands with this commit, which is the clearest way to read the diff:

  • before — "notify mode: nothing opens before the user says go", asserting that even a refresh needing nobody waits for the hotkey;
  • after — "notify mode: silent when the sign-in needs nobody" and "notify mode: notified when it needs you, shown on the go-ahead".

All 10 scenarios pass locally under xvfb, and skipping the notify branch of the hand-over fails exactly those two.

Docs updated: README, docs/docs/login.html, docs/docs/settings-behavior.html, the Behavior panel's own description of the mode, and AGENTS.md.

🤖 Generated with Claude Code

https://claude.ai/code/session_018XK1mi3rSPLzxu7XUhyC6a

@popen2 popen2 added the feature label Aug 31, 2026 — with Claude
Notify mode is a promise not to put a login page in front of the user
unannounced, and it kept that promise by announcing every refresh:
notification, wait for the hotkey, then the login window. With automatic
approval that is backwards. Most refreshes now ask the user for nothing at
all, so notify mode was interrupting them once a working day about work
Frost was about to do without them.

The notification moves to the moment a refresh turns out to need a person.
Frost works through the approval off screen first; if the page asks for a
password, a one-time code or a security key, notify mode says so and waits
for the hotkey or a click before showing anything. A refresh the identity
provider session covers passes in silence. With automatic approval off
nothing changes: a login page is still about to open, so it is still
announced first.

That also makes notify mode able to finish with nobody at the machine,
which is what #92 needed canRefreshUnattended() for. It excluded notify
mode because the old flow waited for a hotkey nobody was there to press;
the new one only waits when the page actually needs a person, so an
overnight refresh in notify mode now renews credentials like any other
instead of stopping before it asks AWS for a device code.

Two details that go with it: the pending trigger is cancelled when the run
ends, or hasPendingAuth() keeps saying yes and swallows the next hotkey
press; and a refresh the user asks for while the notice is unanswered is
them saying yes, so it reaches the page Frost is already holding.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018XK1mi3rSPLzxu7XUhyC6a
@popen2
popen2 force-pushed the claude/frost-auto-approve-e2e-suite branch from 71f60b0 to ec2cd2f Compare September 14, 2026 10:10
@popen2 popen2 changed the title The full end-to-end suite for automatic approval, and notify only when the sign-in needs you Notify only when the sign-in actually needs you Sep 14, 2026
@popen2
popen2 changed the base branch from main to claude/frost-auto-approve-aws-o8yleo September 14, 2026 10:10
Base automatically changed from claude/frost-auto-approve-aws-o8yleo to main September 14, 2026 19:09
@popen2
popen2 merged commit 5075d3a into main Sep 14, 2026
10 checks passed
@popen2
popen2 deleted the claude/frost-auto-approve-e2e-suite branch September 14, 2026 19:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants