Visual companion: support click-to-continue for clickable choices in Codex

[nanmen2]

Visual companion: support click-to-continue for clickable choices in Codex

• I searched existing issues and this has not been proposed before

What problem does this solve?

When using the Superpowers visual companion in Codex, clickable A/B choices are recorded to state_dir/events, but the click does not wake or continue the Codex thread.

In a real brainstorming flow, the page presents A/B choices as if clicking one is a submission. The browser updates visually and the event is written successfully, but Codex remains idle until the user returns to chat and sends another message such as continue.

This came up during a real design brainstorming session, then reproduced in a controlled minimal session on 2026-06-25. In both cases:

• The browser click was written to state_dir/events.
• The Codex session did not advance after the click.
• Codex only read the recorded event after a separate chat message created the next turn.

That points to a missing click-to-turn bridge, not a lost click or a DOM-read problem.

Related searches I ran before filing:

• "visual companion" "click" found #957 and #1053, but neither is about click-to-wake for Codex A/B choices.
• "visual companion" "Codex" found #1100, #1069, #1237, #1773, and #737, but none describes recorded browser clicks failing to create or continue a Codex turn.
• "state_dir" OR "events" "visual companion" found #975, #1014, and #1794, but none is this interaction issue.

Proposed solution

Support a click-to-continue mechanism for visual companion choices in Codex.

Concretely, when the user clicks an element such as <div data-choice="a">...</div>, the visual companion should not only write the event to state_dir/events; it should also notify or wake the active Codex thread so the assistant can read the selection and continue without requiring a separate chat message.

If this is not possible with the current Codex/plugin API, I would like this issue to track that platform limitation explicitly and define what support would be needed. For example, Superpowers may need a supported way for the visual companion server/browser event to submit a user event into the active Codex conversation, or Codex may need to expose a safe API for plugin-originated user input.

What alternatives did you consider?

A smaller UX/documentation fix would be to show a message like:

Selection recorded. Return to Codex chat and send "continue".

That would reduce confusion, but it would not solve the workflow problem. The visual companion is most useful when browser choices behave like direct interaction, especially for A/B design decisions.

The current workaround is:

1. Click A/B in the browser.
2. Return to Codex chat.
3. Send continue.
4. Let the assistant read state_dir/events.

That workaround functions, but it defeats the expectation created by clickable choices.

I am filing this as a feature request rather than a bug report because the current visual companion instructions say events are read on the next turn. The requested change is that clicking a visual companion choice should be able to create or wake that next turn in Codex.

Is this appropriate for core Superpowers?

Yes. This is not project-specific or domain-specific. It affects the general-purpose brainstorming visual companion and any workflow that uses clickable choices in Codex.

It may require coordination with Codex/harness capabilities, but the user-facing behavior is in Superpowers' core visual companion workflow.

Environment (required)

Field	Value
Superpowers version	6.0.3
Harness (Claude Code, Cursor, etc.)	Codex
Harness version	codex-cli 0.142.1; Codex app 26.616.81150
Your model + version	gpt-5.5
All plugins installed	superpowers@6.0.3, browser@openai-bundled, chrome@openai-bundled, documents@openai-primary-runtime, pdf@openai-primary-runtime, spreadsheets@openai-primary-runtime, presentations@openai-primary-runtime, template-creator@openai-primary-runtime

Context

Evidence summary

• Real workflow: I clicked option A in the visual companion. The event was recorded, but Codex did not continue until I typed continue in chat.
• Controlled reproduction: I created a minimal A/B visual companion page, clicked A, waited at least 30 seconds, and saw no new Codex turn. The event file contained choice: "a". Codex only read it after I sent continue.

Original observed workflow

The issue first appeared during a real brainstorming/design task. The visual companion page showed two clickable choices:

• A: accept the proposed information hierarchy.
• B: adjust the proposed layout.

I clicked A in the browser. The browser-side interaction was recorded. Later, after I typed continue in Codex chat, the assistant read state_dir/events and found three recorded A clicks.

The exact label text is not important; the important part is that multiple browser clicks were written to state_dir/events before Codex continued:

{"type":"click","text":"A\n\nAccept this option","choice":"layout-v1","id":null,"timestamp":1782368631519}
{"type":"click","text":"A\n\nAccept this option","choice":"layout-v1","id":null,"timestamp":1782368650634}
{"type":"click","text":"A\n\nAccept this option","choice":"layout-v1","id":null,"timestamp":1782368650800}

This showed that the browser clicks were not lost. They were stored successfully, but Codex did not read them until a separate chat message created a new turn.

Controlled reproduction

I opened a fresh Codex session and used this prompt:

I want to verify the Superpowers visual companion A/B click selection behavior.
Use the brainstorming visual companion to create a minimal A/B selection page
that lets me click A or B in the browser. Do not use request_user_input in chat.
Use clickable visual companion options. After the page is generated, stop and
wait for my selection.

The assistant started the visual companion server and rendered a minimal page with two clickable choices:

• data-choice="a" for option A.
• data-choice="b" for option B.

The assistant then stopped and waited for my browser selection.

I clicked A in the browser and did not send any chat message for at least 30 seconds.

The event file was written immediately:

{"type":"click","text":"A\n    \n      Option A\n      Select A for this visual companion click test.","choice":"a","id":null,"timestamp":1782373549135}

The numeric timestamp is the helper's recorded click time in milliseconds. It is included only to correlate the click event with the Codex session log.

The click occurred after the assistant's "waiting for selection" response, but the Codex session did not continue. The session JSONL remained unchanged after the click; no new assistant turn was created by the browser event.

Only after I sent continue in chat did Codex continue. In that next turn, the assistant read state_dir/events, found the recorded click, and recognized the selected choice as a.

Local session id for the controlled reproduction, in case it is useful for correlating my own logs:

019efdba-2965-7c80-a8c5-bdf969bf285d

The session id is not the primary evidence. The relevant evidence is:

• the browser click produced a state_dir/events entry,
• the Codex conversation did not advance after the click,
• the same recorded event was read only after a separate chat message created the next turn.

[hiSandog]

This seems like it needs a small turn-wakeup contract rather than just recording the click event. The bridge should probably include the Codex session/thread id and an event id so a click can wake exactly one pending turn, and repeated clicks can be deduped. A regression test could write a visual companion choice event and assert that the waiting Codex session advances without requiring a separate user chat message.

[obra]

Is there an API to do this easily with Codex? We'd like to do this, but the harnesses don't generally provide a way to inject a turn into a running session. As of right now, we can't make this work without blocking the user from being able to send a turn in the terminal.