You click “Approve” in an agent dashboard. Does it still mean the action you reviewed?
Imagine a coding session asking to change a configuration file. You read the request, leave the tab open, and return later. Meanwhile, someone answered in the terminal, the task restarted, or the proposed change was revised. The button still looks ready.
That is the first test I would write for a browser-based agent control panel. Showing a request and authorizing it are different responsibilities. The runtime must reject a click that no longer refers to the pending action.
Ed Engelking II’s Podium launch post prompted this question. Podium offers optional browser responses to waiting Claude Code sessions. I have not audited its implementation or shipped such a console. These are the conditions I would require before adding that capability to my own workflow.
Bind the decision to the exact request
Each pending request needs an identity, an expiration, and a version. An approval must refer to a particular session instance and the exact proposed action. A session name alone is not enough.
If the proposed configuration change is revised, the old approval expires. A restarted task cannot inherit a click meant for its previous instance. If the terminal already answered, the browser should show that result instead of submitting another answer.
The runtime must check these conditions when the answer arrives. The browser cannot decide whether the request is still pending. In this design, the console must also respect denials imposed by the runtime’s policy.
Show what happened after the click
A browser submission, a server acknowledgement, runtime acceptance, and a completed action are separate events. The interface should say which one it has evidence for.
Suppose the browser disconnects just after sending approval. A retry with a new request identity could duplicate an effect. Keep the original identity, ask what happened, and show “unknown” until the result is known.
This is the problem in The agent timed out. Did the action happen?. A successful submission does not establish that the configuration file changed.
Give viewing and acting separate permissions
A person allowed to read a transcript should not automatically be allowed to send its next instruction. Answering an ordinary question and authorizing a tool action also need separate permissions.
I would add these capabilities in stages: read-only observation first, then answers to a narrow class of questions, then remote tool approval with its own tests.
For a team, permissions should specify the project, session, and action. A shared wall screen may need to show that an agent is blocked without exposing its prompt. Audit records should identify who answered which request without retaining every secret in the transcript.
Anthropic’s mods documentation says mods run with the user’s permissions and are not sandboxed. Installing a mod therefore requires trust in its code. That trust does not establish that a web console built around it authorizes browser users correctly.
Make stale and duplicate answers fail safely
I would test expired requests, revised changes, restarted sessions, revoked permissions, and disconnected reporters. Each case should leave the interface clear about whether an answer can still be accepted.
Then I would send duplicate answers and answer simultaneously from the terminal and browser. One valid answer should win; the other interface should learn that the request is already resolved. Two approvals cannot independently succeed for one pending request.
Finally, take the console offline. Losing the dashboard must not turn a required approval into permission to proceed.
Fewer windows and fewer forgotten questions are worth pursuing. But the approval button earns its place only when it authorizes exactly the action the person reviewed.