The approval the browser could not see

Claude was waiting for permission to write a file. The browser had received the approval request, but its Work Room still said “Working.” There was no button to press. Waiting longer did not help because both sides were obeying their own state: Claude's Hook blocked for an answer, while the browser showed approval cards only when the provider lifecycle said it was awaiting approval.

The missing event sat between those two facts. The native PermissionRequest Hook forwarded an OIP approval_needed message, but the provider invocation remained running. We reproduced the stall with a real Haiku turn after a terminal-to-browser handover. The WebSocket frame arrived and the file was never written.

The fix emits a revisioned awaiting_approval lifecycle event before asking the owner and a running event after the decision. The same browser test then showed Allow once; accepting it let Claude write the exact requested file and reply. Focused unit tests cover event order and revision increase.

The test also exposed a misleading permission menu. Station always uses Claude's native default mode for browser turns so the owner can review edits, yet the Work Room offered “Auto.” Station now declines profile changes and stops advertising the profile catalog. The UI displays its fixed approval policy instead.

This closes one visible gap, not the whole distance to Happy. Our bridge still asks the owner only about workspace file edits. Shell commands, MCP calls, questions, and plan changes need explicit presentation and decision rules before the Work Room can offer the same control without weakening its workspace boundary.

The bridge fix is included in the opt-in 1.8.9b5 preview. The O Chat label change is tracked separately, so installing the Python preview alone does not change the already deployed browser interface.