[Feature]: Add configurable follow-up behavior while a turn is running

[leonardoxr]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

When Codex is already running and I think of a correction or follow-up, T3 Code does not expose a clear follow-up contract.

Right now the composer swaps the send action for a stop button while a turn is running, but there is no explicit setting that lets me choose what a new follow-up message should do in that state:

• queue the message for the next turn after the current run finishes, or
• steer/intervene in the current run

That makes mid-run guidance feel ambiguous and less predictable than Codex’s native follow-up behavior.

As a secondary "feature" this can be used as a janky "ralph loop", i used it to send lots of repeated "Continue your work" to make the agent work for a long time(i know it's silly, but it helped the development proccess)

Proposed solution

Add a configurable Follow-up behavior setting with two modes:

• Queue: hold the message and send it automatically after the current turn completes
• Steer: treat the message as guidance for the current run

The composer should surface the active behavior while a turn is running, and it should support a one-off override so the user can do the opposite behavior for a single message.

The important part is that send behavior becomes explicit and consistent across both button submit and keyboard submit paths.

Why this matters

Long-running agent turns often need course correction before they finish. Making follow-up delivery explicit reduces accidental interrupts, avoids unnecessary waiting, and makes the app feel more reliable under load, reconnects, and partial streams.

Smallest useful scope

Add a global client setting for Follow-up behavior with Queue and Steer, and make composer submits respect that setting whenever a thread already has a running turn.

If needed, the first version can limit queued follow-ups to a single pending message per thread.

Alternatives considered

• Always interrupt/steer the current run
• Always block follow-up sends until the run completes
• Ship only one behavior in v1 with no setting

Risks or tradeoffs

Queued follow-ups need a clear lifecycle around interrupts, reconnects, session restarts, and failed turns so messages are not lost or replayed unexpectedly.

Steering behavior also needs clear UX copy so the user understands whether the current run will stop immediately or at the next safe boundary.

Examples or references

Codex follow-up behavior UI (Queue / Steer) shown in the attached screenshot

Contribution

• I would be open to helping implement this.