Skip to content

[Feature]: Mid-turn message steering on mobile (parity with desktop injection) #7234

Description

@simonseifert

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/mobile

Problem or use case

On desktop, a message sent while the agent is working is injected into the running turn — the agent sees it mid-task and can change course immediately. On mobile the same message is queued and only delivered once the turn ends.

That difference matters most in exactly the situation mobile is best at. A typical session: the agent is running a long task, I'm away from the desk with only my phone, and I can see from the output that it's about to do something I don't want. On desktop I'd redirect it in one line. On mobile I can only watch it finish and correct it afterwards, which wastes the whole turn.

It's most acute for long-running work — builds, migrations, multi-step operations — which is precisely when you're least likely to be sitting at the desktop.

Related: #5436 (queued mobile messages are dropped entirely if the app backgrounds) compounds this, since the queued message may not even arrive at the end of the turn.

Proposed solution

Give mobile the same mid-turn injection path the desktop uses, so a message sent while the agent is working reaches it immediately rather than waiting for turn end.

If both behaviours are worth keeping, a per-message choice would be ideal — send now versus queue for after — since "queue this for when you're done" is genuinely useful too, just not the only thing you ever want.

Why this matters

Mobile's core value is checking in and steering while away from the desk. Without injection it's read-only in practice during the exact moments when intervention is most valuable, and a wrong turn costs the whole run rather than one line of correction.

Smallest useful scope

Mid-turn injection on mobile matching current desktop behaviour, even without a per-message send-now/queue toggle.

Alternatives considered

Queueing (#5507, #267) already shipped and is the right default for "do this next". It isn't a substitute for steering, since by the time a queued message lands the turn is over.

Risks or tradeoffs

Injection mid-turn is more disruptive than queueing, so if only one behaviour can be the default, some users may prefer the current one. That argues for a toggle rather than a straight switch.

Contribution

  • I would be open to helping implement this.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions