Summary
When an agent retries or restarts the visual-direction decision page after failures, multiple browser tabs can open at once — each pointing at a different localhost port — instead of reusing a single tab or updating the existing one.
Environment
- Skill: Impeccable
serve-question.mjs --start flow
- OS: macOS (
open command)
- Harness: Cursor agent
Steps to reproduce
- Agent runs
serve-question.mjs --start --payload direction-roll.json → prints QUESTION URL: http://127.0.0.1:51735/ and QUESTION KEY.
- Agent runs
open "http://127.0.0.1:51735/" (Tab 1).
- User closes tab or page times out; agent restarts with
--start on a new port → http://127.0.0.1:51761/.
- Agent runs
open "http://127.0.0.1:51761/" (Tab 2).
- Agent fixes payload and restarts again →
http://127.0.0.1:51953/.
- Agent runs
open "http://127.0.0.1:51953/" (Tab 3).
Expected
- One decision surface for the user: either reuse the existing tab/window, or open once on the final URL.
- Retries should use
--update --key <key> when the server is still alive, or clearly instruct the user to close stale tabs.
new-work.md says: "open that URL for the user, in-app browser first, then the system opener" — implying a single presentation, not one tab per retry.
Actual
- Three browser tabs opened at once, each on a different localhost port (51735, 51761, 51953).
- Only the latest tab was live; the first two pointed at dead servers.
- The user had to manually close stale tabs and figure out which URL was current.
Impact
- Confusing UX during an already-interactive decision step.
- Looks like a bug in the harness/skill coordination, not just agent error.
- Easy to accidentally answer on a dead tab or miss the active one.
Suggested fix
One or more of:
- Document: In
serve-question.mjs / new-work.md, instruct agents to call open once (on final --start), or reuse --update instead of restart + re-open.
- Stable port/key: Option to bind a fixed port or reuse the same
--key so retries replace the live page instead of spawning new servers.
- Stop before restart: Agent playbook: always
--stop --key before a new --start, and do not open again unless the user closed the tab.
- Harness hook: If the IDE has an in-app browser, route URL updates there instead of shelling out to
open on every retry.
Session notes
This occurred during a single Cursor agent session building an Ekihana Stand home page. The agent restarted the question server twice (page closed without answer; then sketch-loading fix). Each restart triggered a new open, leaving three tabs open simultaneously.
Summary
When an agent retries or restarts the visual-direction decision page after failures, multiple browser tabs can open at once — each pointing at a different localhost port — instead of reusing a single tab or updating the existing one.
Environment
serve-question.mjs --startflowopencommand)Steps to reproduce
serve-question.mjs --start --payload direction-roll.json→ printsQUESTION URL: http://127.0.0.1:51735/andQUESTION KEY.open "http://127.0.0.1:51735/"(Tab 1).--starton a new port →http://127.0.0.1:51761/.open "http://127.0.0.1:51761/"(Tab 2).http://127.0.0.1:51953/.open "http://127.0.0.1:51953/"(Tab 3).Expected
--update --key <key>when the server is still alive, or clearly instruct the user to close stale tabs.new-work.mdsays: "open that URL for the user, in-app browser first, then the system opener" — implying a single presentation, not one tab per retry.Actual
Impact
Suggested fix
One or more of:
serve-question.mjs/new-work.md, instruct agents to callopenonce (on final--start), or reuse--updateinstead of restart + re-open.--keyso retries replace the live page instead of spawning new servers.--stop --keybefore a new--start, and do notopenagain unless the user closed the tab.openon every retry.Session notes
This occurred during a single Cursor agent session building an Ekihana Stand home page. The agent restarted the question server twice (page closed without answer; then sketch-loading fix). Each restart triggered a new
open, leaving three tabs open simultaneously.