[iamnbutler]

Ask to join now tells both people where the request stands: the owner sees it as it arrives, and the asker sees when it lapses and when they're let in (^120).

Asker (Team setup → Ask to join)

• Waiting… stays until the ask ends. It compared peers by object, so the peer list's 5 s refresh turned it into a disabled Ask to join with nothing said.
• The hint now names when the request lapses: "Asked samechocolixir to approve it in their Ace. You join as soon as they do; the request lapses at 4:40 PM if nobody answers." The host and the app share the 5-minute limit (TEAM_ASK_EXPIRES).
• Being let in shows a toast ("samechocolixir let you in"), since joining closes Team setup. A lapsed or declined ask still shows the host's reason in the form.

Owner

• An ask that arrives while Ace isn't focused sends a desktop notification: "Let iamnbutler join your team?"
• The dialog says when the request lapses.
• Approve confirms with "Let iamnbutler in — natembp has your team's directory and joins it now". Deny confirms with "Declined iamnbutler's request".

Smoke test
An isolated owner host (own ACE_HOME, config, keychain service, port 4955) shared on the tailnet listener, with its app in headless Chromium. A real peer ask came in through GatewayClient over ws://<tailnet ip>:4955/ws:

• The dialog appeared live with "The request lapses at 4:40 PM".
• Approve showed the toast, and the asker got the directory URL and secret.
• A second ask with Deny showed "Declined iamnbutler's request", and the asker got "They declined. Ask them for an invite link instead."

Not checked

• The asker's Team setup UI needs a second machine on the tailnet in a team, so it was checked only by type checks.
• The desktop notification needs the desktop app.
• When Ace is quit, only Ace Helper is running, and it has no way to notify. That's still open.

Part of #632 (the quit-app case remains).

Built in Ace

No. This was made from Claude Code as a fix-train worker, using a headless Chromium and a Bun script as the asking peer. Ace has no way yet to run an agent-driven fix queue across several workers like this (#5).