Skip to content

Architect input: inbound afx send collides with user's in-progress draft #853

@amrmelsayed

Description

@amrmelsayed

Problem

When the user is typing in the architect input box and an afx send arrives from a builder (or any other source), the inbound text is appended to whatever the user has typed and the combined buffer is submitted as a single message. The user's draft is mangled, and a half-formed thought gets sent to the AI alongside an unrelated inbound message.

Repro

  1. Start typing a multi-line prompt in the architect terminal — don't press Enter.
  2. From another shell: afx send architect "anything" (or have a builder send back via affinity).
  3. Observe: inbound text is concatenated onto the draft and submitted together. The user's draft is lost as a coherent message.

Why it happens

afx send to the architect delivers via the same PTY stdin that the user's keystrokes flow through. Tower writes the inbound payload + newline directly, so any pending draft in the line-editor buffer gets prepended to the inbound text and submitted by the newline.

Proposed fix

Tower mediates the PTY — it can buffer inbound messages instead of always writing them through immediately.

  • Track user draft state: chars typed since last newline, time since last keystroke.
  • When afx send arrives and the draft buffer is non-empty (or recent keystroke activity within ~N seconds), enqueue the inbound message rather than writing it.
  • Flush the queue when one of:
    • User submits (Enter) — flush after the user's message lands.
    • User clears the line (Ctrl+U, Ctrl+C).
    • Input has been idle for N seconds with empty buffer.
  • Surface a small indicator in the Tower UI ("1 message queued from builder 0823") with a manual-flush affordance, so the user knows something is waiting and can deliver it themselves.

Open questions for the implementer:

  • How is "draft non-empty" detected — does Tower already echo-track the PTY, or does it need to instrument the line editor? (Different per architect CLI: claude vs codex.)
  • What's the right idle threshold? Probably ~2-3s.
  • Should the queue persist across architect restarts? (Probably no — inbound messages are tied to the current conversation context.)

Impact

User-facing data loss risk: the user's typed prompt gets submitted in a state they didn't intend, often producing an irrelevant AI response to a Frankenstein message.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/towerArea: Tower server / agent farm CLI

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions