Repository navigation
Non-interactive pipe mode for forge -p to enable editor integration #3459
Description
I frequently want to pipe text through forge -p in shell pipelines and editors. The problem is that forge -p outputs ANSI codes, reasoning blocks, status indicators, and syntax highlighting — all designed for human reading in a terminal. This makes it difficult to use forge as a composable shell tool where only the raw model response is desired.
Use cases this would unlock:
- Shell pipelines:
echo "data" | forge -p "transform this" | jq/awk/sed ... - Editor integration: Pipe selected text through forge, replace selection with result (Helix, Vim, VS Code, etc.)
- Scripting: Use forge in automated workflows where the output feeds into another program
- Clipboard workflows: Pipe clipboard content through forge, pipe result to clipboard
The forge suggest command already demonstrates this pattern — it outputs clean, pipeable shell commands. Something similar for forge -p would make forge a general-purpose composable tool rather than something that only works well interactively.
Activity
ictechgy commentedon Jul 2, 2026
Adding a concrete automation angle to this request.
For multi-agent review wrappers,
forge -pneeds a stable boundary between human-oriented progress/trace output and the assistant's final answer. In observed prompt-mode runs, stdout can include trace records such as initialization, file reads/searches, and then the final review content in the same stream. That makes wrappers brittle: they have to guess where progress ends and the answer begins.A non-interactive output contract would help, for example:
A minimal JSON response such as
{ "status": "ok", "final": "..." }would be enough for many wrappers. If trace/progress is still needed, it could be omitted in final-only mode, sent to stderr, or exposed through a separate structured streaming mode.github-actions commentedon Aug 1, 2026
Action required: Issue inactive for 30 days.
Status update or closure in 7 days.
0chroma commentedon Aug 1, 2026
still a missing feature. I think maybe like
--no-color,--hide-reasoning,--plainor something like that would be good. The process' status code tells us if it failed or not.github-actions commentedon Aug 31, 2026
Action required: Issue inactive for 30 days.
Status update or closure in 7 days.
github-actions commentedon Sep 7, 2026
Issue closed after 7 days of inactivity.