Add a way for agents to monitor and optionally interrupt long-running commands

[bjsi]

• Some github issues involve debugging commands that hang. When writing code to reproduce and fix these kinds of issues, an autonomous agent needs a way to monitor and optionally interrupt the command if necessary.
• After running a particular shell command, every 10 seconds or so it should add a message to the conversation log giving some context about what the command is doing, whether it is still running etc and asking whether it wants to kill it.

[bjsi]

From Jake:

Current Understanding

• Issue 348 requests a way for agents to monitor and optionally interrupt long-running commands.
• The execute_shell function in gptme/tools/shell.py is the main entry point for executing shell commands.
  • It uses get_shell_command to construct the command string.
  • The actual execution is done by execute_shell_impl.
• execute_shell_impl function:
  • Uses a ShellSession object to run the command.
  • Captures stdout and stderr.
  • Formats the output into a message.
  • Yields a system message with the command output.
• The ShellSession class manages the shell environment:
  • It uses subprocess.Popen to create a shell process.
  • The run method executes commands in this shell.
• The LogManager class in gptme/logmanager.py is responsible for managing the conversation log.
  • The append method is used to add new messages to the log.
• There's currently no implementation for monitoring long-running commands or interrupting them.
• The issue suggests adding messages to the conversation log every 10 seconds for long-running commands.

Questions to Investigate

1. How can we modify execute_shell_impl to monitor the duration of running commands?
2. What's the best way to implement a timer for periodic updates (every 10 seconds) during command execution?
3. How can we add these periodic status updates to the conversation log using LogManager?
4. What information should be included in the periodic status updates (e.g., execution time, current status)?
5. How can we implement an interruption mechanism for long-running commands?
6. Where in the code should we add the logic to prompt the user about potentially killing a long-running command?
7. How can we modify the ShellSession.run method to support monitoring and potential interruption?
8. What's the best way to handle the interruption if the user decides to kill the command?
9. How can we ensure that the monitoring and interruption features don't significantly impact performance for short-running commands?

[ErikBjare]

You can sort of do this by forcing/instructing the agent to use the tmux tool instead and then "undo" when it's not ready (as in the https://github.com/ErikBjare/gptme/blob/master/scripts/treeofthoughts.py script) since otherwise it'll eat tokens like crazy.

[ErikBjare]

@gptme read some relevant source files and tell us what you think

[github-actions]

Based on the analysis of the gptme/tools/shell.py and gptme/tools/tmux.py files, I recommend using the tmux tool as the primary approach for implementing monitoring and optional interruption of long-running commands. Here's a summary of the proposed solution:

1. Leverage the existing tmux tool functionality:

   • new_session: Start long-running commands in isolated tmux sessions.
   • inspect_pane: Periodically check the status and output of commands.
   • send_keys: Send interruption signals if needed.
   • kill_session: Forcefully terminate sessions if necessary.

2. Implement a new monitor_session function in the tmux tool:

   • Periodically inspect the pane content of a given session.
   • Yield status updates to the conversation log every 10 seconds.
   • Check for command completion or the need for interruption.
   • Allow user-triggered interruption for long-running commands.

3. Modify the execute_tmux function to handle the new monitor_session command.

4. Update the tmux tool's instructions and examples to include the new monitoring functionality.

Advantages of this approach:

• Leverages existing tmux functionality for process isolation and management.
• Allows for easy monitoring of multiple concurrent long-running commands.
• Provides a flexible solution that can be extended for various use cases.
• Integrates well with the existing conversation log system.

Implementation steps:

1. Add the monitor_session function to gptme/tools/tmux.py.
2. Modify the execute_tmux function to handle the new command.
3. Update the tool's instructions and examples.
4. Add appropriate error handling and edge case management.

This solution addresses the requirements outlined in Issue #348 while maintaining the flexibility and power of the existing tmux tool. It provides a robust way for agents to monitor and optionally interrupt long-running commands, enhancing the overall capabilities of the gptme system.