bash long_running_reminder_enabled: false does not suppress completion reminders

[Vulcankta]

Short description

bash long_running_reminder_enabled: false does not suppress completion reminders

What happened?

Description

Setting bash.long_running_reminder_enabled: false in user-level config does not suppress background bash completion <system-reminder> messages. The config field is parsed and stored in ResolvedBashConfig, but no gate was wired in the notification pipeline.

Reproduction

1. Set in ~/.config/opencode/aft.jsonc:

   "bash": {
     "rewrite": false,
     "compress": false,
     "long_running_reminder_enabled": false
   }

2. Run a command that gets promoted to background (e.g. sleep 12)
3. On next tool call, a block still appears with [BACKGROUND BASH COMPLETED]

Root cause

The config field is parsed and stored in ResolvedBashConfig, but the bash tool sets notify_on_completion unconditionally without checking it. The notification pipeline (handlePushedBgCompletion → appendInTurnBgCompletions → formatCombinedSystemReminder) never reads this config field, so the gate was never wired.

The Rust side (bash_long_running_reminder_enabled) receives the flag but doesn't need it — the gate belongs on the TypeScript side where the <system-reminder> is injected.

Config

• Plugin: @cortexkit/aft-opencode v0.35.1
• Binary: v0.35.1
• Platform: Windows x64

Diagnostics

Plugin version

0.35.1

AFT binary version

0.35.1

Platform

windows x64

Log output (optional)

[alfonso-aft]

Thanks for the detailed report, and your read of the code is accurate. That flag (long_running_reminder_enabled) only gates the periodic "still running" nudge for in-flight tasks. The completion reminder you're seeing is a separate path by design, which is why the flag doesn't touch it.

We deliberately don't have a switch to disable completion reminders, and the reasoning is: the completion reminder is how the agent learns a background task finished. We actively steer agents away from polling bash_status, so without that reminder the agent has no signal the task is done and would either wait forever or never read the result. A knob to turn it off would mostly just break background bash.

Before we decide whether to add anything, what are you actually trying to achieve? For example, are the reminders too noisy or firing too often, are they interrupting something specific, or is there a different way you'd want completion delivered? Knowing the underlying goal lets us fix the real problem rather than ship a footgun.