Fix editor clearing draft text on queued steering messages in pi's TUI
Session from pi-mono-sessions on Hugging Face by thomasmustier · MIT · condensed by Coders Talk
Investigate and fix a bug where sending a queued steering/follow-up message clears whatever draft text the user is currently typing in pi's interactive TUI, then prepare a PR and issue writeup for it.
- +0Prompt · +0There's a bug in pi where queuing steering messages clears the input text box when one sends. Please investigate.
- +0mAgent did · +0mSearched the coding-agent and tui packages for the input/editor/steering logic, traced through interactive-mode.ts and editor.ts to find where message_start handling clears the editor text on incoming user messages.
- +3mAgent did · +3mRemoved the `this.editor.setText("")` call on user message_start in interactive-mode.ts so queued steering messages no longer wipe the draft input; ran `npm run check` to verify.
- +5mPrompt · +5mWhat was the purpose of this line? Find out when it was introduced, why, and whether removing it breaks anything.
- +5mAgent did · +5mUsed git blame and git log -S to trace the setText call back to commit 0020de851 (WP15: Create InteractiveMode using AgentSession, Dec 9 2025), and reasoned the clear was likely a redundant safety net since the editor already clears itself on submit.
- +11mPrompt · +11mSync with upstream, reapply our change locally, and check for open issues/PRs already addressing this.
- +11mAgent did · +11mStashed the change, pulled --rebase from origin/main, popped the stash to reapply the fix, re-ran checks, and searched gh issues/PRs for related open items — found none tracking this bug.
- +20mIntervention · +20mAsked for a much deeper investigation into why the original clearing behavior was introduced and whether anything in the current implementation still relies on it before shipping the fix.Why: I wanted to be really sure this one-line deletion wasn't masking a dependency elsewhere before opening a PR.
- +20mAgent did · +20mTraced message_start handling through agent-session.ts and agent-loop.ts, checked extension APIs like sendUserMessage, and re-confirmed via git history that the clear was redundant even at introduction since the editor self-clears on submit.
- +20mAgent did · +20mPushed the fix to a new fork branch (fix/steering-input-preserve), drafted and iterated a PR description and GitHub issue writeup referencing the investigation, and exported a large session .jsonl transcript to Markdown for sharing.
- +20mOutcome · +20mOne-line fix committed and pushed to fork branch fix/steering-input-preserve; npm run check passed; PR description and GitHub issue writeup drafted with root-cause analysis and session transcript exported to Markdown.
Next time I'd ask upfront for both the fix and a git-history deep dive on the offending line, since that back-and-forth took longer than the fix itself. Pushing back on tying the PR to issue #475 and asking for a serious 'what else depends on this' investigation were the interventions that actually mattered — they caught that the original clearing behavior was already redundant rather than load-bearing. The one-line deletion held up under scrutiny, which gave me confidence to ship it.