How to use Codex to coordinate a rescue simulation
Codex coordinated four simulated rescue robots through WebMCP, with one human-approved mission, temporary execution authority, a receipt, and tool revocation.
devpost.com
Suggested prompt
Suggested prompt written by Agents In Use, not the source author. Replace bracketed inputs and review tool permissions first.
In the current Firebreak tab, use only its WebMCP tools to inspect the emergency, scan hazards, check robots, and validate a rescue plan. Do not search the web or invent routes. Present the exact plan for my approval, execute only the one-use capability afterward, and report the receipt and removal of execution authority.
Reach people exploring AI agents
See placements →What happened
Firebreak demonstrated inspection, checked planning, human approval, one-use execution, and capability removal for a four-robot browser rescue simulation.
Reported by Bilgin Koçak — DevpostHow the agent did it
- Codex inspected and planned the simulated rescue through the page’s available WebMCP tools.
- The human reviewed the exact checked plan and approved a temporary execution capability.
- After execution the application issued a receipt, revoked the tool, and rejected stale plans when state changed.
Where a person stepped in
Only the human could authorize the rescue; the agent had no approval tool. The owner distinguished scripted demos from live tool calls and reviewed the displayed mission boundary.
Bilgin Koçak built Firebreak to test whether a browser agent could coordinate four simulated emergency robots while a human controlled the mission boundary. The warehouse scenario included trapped workers and an exposed battery container, but no physical robots were operated.
At first, Codex could inspect hazards, check robots, create routes, and validate a plan through seven WebMCP tools. Those tools could not move the fleet. When the plan passed the application’s safety rules, a person could inspect and approve the exact rescue. Only then did a one-use execution tool appear.
The completed mission produced a receipt and removed that temporary tool. Changes to warehouse state invalidated earlier plans, preventing an old approval from authorizing a different situation. During development, an agent tried searching GitHub instead of using the current page; the owner clarified the task prompt and added a live trace distinguishing real tool calls from a scripted walkthrough.
The account reports browser and unit checks for refusal, planning, approval, execution, and revocation. Its result is a tested coordination experiment inside a browser simulation. A limited robot bridge had only a fake test adapter, so the demonstration does not establish safe real-world rescue behavior.
Prompt
Suggested prompt (written by Agents In Use, not the author's)
Source: Devpost · Bilgin Koçak
Frequently asked questions
Could the agent approve its own mission?
No. Approval belonged to the person using the page.
What happens to an old plan after state changes?
The application rejects its stale safety proof.
Were physical robots operated?
No. The account explicitly describes a browser simulation and a fake bridge test.
More details
About this account
Codex inspected and planned the simulated rescue through the page’s available WebMCP tools. The human reviewed the exact checked plan and approved a temporary execution capability.
Opened original account; browser-simulation status and fake bridge are explicit. Prompt is our targeted runtime suggestion, not a claimed original. Safety-rule behavior is developer-reported verification. Suggested prompt written by Agents In Use; no original task prompt was published in the verified account.
Credit: Bilgin Koçak — Devpost
Source published 2 Sept 2026
Source checked 14 Oct 2026
Tools and topics
Codex · WebMCP · Babylon.js · React · Playwright
rescue simulation · temporary authority · human approval
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.