Allow configuring how background task notifications render in the terminal

Status Open
Maintainer reply None cached
Activity 0 comments · opened Sep 4, 2026

Problem

When a background agent fires a task notification and the parent session has no action to take, the terminal renders an empty Human: turn. Multiple of these in succession create visual noise that makes the conversation hard to follow and looks like a broken session.

More critically: in at least one observed case, a task notification arriving between an assistant question ("Good to post?") and the user's actual response was rendered as Human: post it — text the user did not type. The assistant treated it as user approval and executed the action (creating a GitHub issue). This is an input integrity problem: the agent acted on an instruction the user never gave.

Current behavior

[collapsed] 1 background command completed
Human:
[collapsed] 2 background commands completed  
Human:

And in the more serious case:

Assistant: ... Good to post?
[collapsed] 2 background commands completed
Human: post it          <-- user did not type this
[tool call: Created issue]

Desired behavior

  1. Input integrity. Task notifications must never be rendered or interpreted as user input. An assistant waiting for user confirmation must not receive a notification artifact as if it were the user's answer.
  2. Suppress empty turns. If the assistant produces no output in response to a task notification, don't render a Human: line.
  3. Configurable notification rendering. Allow a hook (e.g., on-task-notification) that runs a shell command whose stdout replaces the default rendering — so users can show a one-line status from their own tooling without the assistant spending tokens.
  4. Batch consecutive silent notifications. Collapse multiple no-response notifications into a single line like [5 background tasks completed].

View original on GitHub ↗