[FEATURE] Advanced Process Control and Interaction for Background Commands

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The current toolset for managing background processes in Claude Code is limited to starting (Bash), monitoring output (BashOutput), and forcefully terminating (KillBash). This binary "run or kill" model is too blunt for many real-world development and debugging scenarios.

Experienced developers rarely rely on just killing processes. They use a variety of signals for graceful shutdowns, configuration reloads, and process management. For example:

• Sending Ctrl+C (SIGINT) to gracefully stop a server, allowing it to clean up resources.
• Sending a SIGHUP signal to a daemon to make it reload its configuration file without a full restart.
• Temporarily pausing a resource-intensive process with SIGSTOP to free up CPU/memory, then resuming it with SIGCONT.

The agent is currently incapable of performing any of these nuanced actions. Furthermore, it cannot interact with any command-line tool that requires standard input (stdin), which blocks it from using a vast number of common CLI utilities that prompt for confirmation (e.g., "Are you sure? [y/N]"). This severely limits the agent's ability to act as an autonomous and effective development partner.

Proposed Solution

I propose introducing a suite of new tools to give the agent sophisticated, developer-like control over the background processes it manages.

1. PauseBash(shell_id):

• Sends a SIGSTOP signal to the process, immediately suspending its execution.
• This allows the agent to temporarily halt a process to free up system resources or to inspect a state without the process continuing to change.

1. ResumeBash(shell_id):

• Sends a SIGCONT signal to a paused process, resuming its execution from where it left off.

1. SignalBash(shell_id, signal):

• A general-purpose tool to send any specified POSIX signal to a process.
• The signal parameter could accept common signal names ('SIGHUP', 'SIGINT', 'SIGTERM') or their integer equivalents.
• This unlocks critical workflows like graceful shutdowns and configuration hot-reloading.

1. WriteToBashStdin(shell_id, input):

• Writes a given string to the standard input of a running background process.
• The input string should support special characters like \n to simulate pressing the Enter key.
• This would enable the agent to interact with prompts from CLI tools, dramatically expanding the range of commands it can use.

Together, these tools would provide the agent with a complete and nuanced set of controls for process interaction, far beyond the current "kill" command.

Alternative Solutions

• Current Workaround: The only existing control is KillBash, which is equivalent to a SIGKILL. This is a brute-force approach that prevents graceful shutdowns, cleanup routines, and any form of nuanced interaction. There is no workaround for pausing, resuming, or sending specific signals.
• Stdin Workaround: There is currently no viable workaround for interacting with a process's standard input. The agent is completely blocked by any tool that requires interactive confirmation.
• Complex Wrapper Scripts: An agent could theoretically try to write a complex bash script that uses trap to handle signals, but this is impractical, error-prone, and moves the control logic away from the agent itself, defeating the purpose of an interactive, agentic workflow.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

A developer is working on a web service and needs to update a configuration file that the live development server is using.

1. User: "I've updated the config.yaml. Please apply the changes to the running dev server without restarting it."
2. Claude: "Okay, I see the dev server is running in the background (sh-456). Instead of a full restart, which would be slow, I will send it a SIGHUP signal to trigger a hot-reload of its configuration."
3. Claude (Internal Logic): Executes SignalBash(shell_id="sh-456", signal="SIGHUP").
4. (The server process receives the signal, reloads config.yaml, and continues running without dropping connections.)
5. Claude (Proactively): "I've sent the reload signal. I am now watching the server's logs to confirm the new configuration has been successfully applied."
6. (Later) User: "Okay, now run the database seeding script. It will ask for confirmation because it targets the staging database."
7. Claude: "Understood. Starting the seeding script (sh-789)."
8. Seeding Script Output: WARNING: You are targeting the staging database. Are you sure you want to continue? (yes/no):
9. Claude (To User): "The seeding script is asking for confirmation to proceed against the staging database. How should I respond?"
10. User: "Type 'yes'."
11. Claude (Internal Logic): Executes WriteToBashStdin(shell_id="sh-789", input="yes\n").
12. Claude: "I have confirmed the prompt. The seeding is now in progress."

Additional Context

• This is the third of three related feature requests designed to create a comprehensive process management framework for the agent. This feature would be most powerful when combined with the proposed "Rich Process State" and "Event-Driven Reactivity" features.
• Security: These are powerful tools. Their use should be governed by the existing permissions system. For example, a user should be able to specifically allow or deny tools like SignalBash or WriteToBashStdin in their settings.json.