Skip to content

Option to run long bash commands in the background instead of blocking in the foreground #365

Closed

Description

@null-axiom

Description

Add a config option, for example bash.prefer_background_for_long: true (default false, so nothing changes for existing users). When it's enabled in a primary (non-subagent) session:

  • Quick commands behave exactly as they do today and return inline.
  • The bash tool description recommends background: true for commands known to be long, such as builds, full test suites, deploys and installs. The agent then ends its turn or does other work, and the completion reminder wakes it.
  • wait: true is presented as the exception, for when the result is needed right away. It's no longer the recommended way to run long commands.
  • Subagents keep the current guidance, since they need results before they report back. subagent_background already covers them.

Today the description says the opposite: "use bash({ command, wait: true }) when you know it is long", "background: true is ONLY for when you have OTHER useful work", and "Do NOT background a command and then immediately bash_watch it".

Use case

In an interactive session, the main agent is often the user's point of contact while subagents do the work. When it blocks on a multi-minute build, test run or deploy, it isn't available to the user until the command finishes or the user sends a message to detach it. We'd rather it start the job in the background, stay free, and pick up the result when the completion reminder arrives.

A prompt can't fix this. Our agent prompt says "Run long-running commands in the background", but the tool description says the reverse, and the model usually follows the tool description. So the agent gets contradictory instructions and doesn't behave consistently.

This is a preference, not a bug. #124 asked for the opposite, keeping long validation commands in the foreground so the agent doesn't burn context while waiting, and that was solved with a config switch. An opt-in option would let both kinds of users get what they want.

Environment: @cortexkit/aft-opencode 0.57.2, OpenCode Desktop on macOS.

Activity

  1. aft-alfonso commented on Sep 26, 2026

    @aft-alfonso

    Thanks, the use case is clear, and you're right that a prompt can't override the tool description here: the description is where the model reads its instructions for this one tool. An opt-in switch that changes only the primary-session guidance, leaving subagents and default behaviour alone, fits the way #124 was handled. I'll confirm the design here before we build it.

  2. null-axiom commented on Oct 22, 2026

    @null-axiom
    Author

    Actually, on second thought, this one doesn't need to exist. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions