programmatically drive claude instances

Resolved 💬 5 comments Opened Jul 3, 2025 by nitsanavni Closed Aug 20, 2025

Could be done with all sorts of APIs: expose an http server, via the cli, MCP (meaning each instance of claude could expose its own MCP server, or register itself to a global MCP server of all claudes on the system, to make itself discoverable and callable from other claudes)

$ claude instance list
1: my-python-project-main-worktree     cwd: /User/username/code/my-python-project/
2: my-python-project-topic1-worktree   cwd: /User/username/code/my-python-project/wt/topic1/

$ claude instance get-last-messages --instance-id 2 -n 2
Bash(pytest)
Great! All tests pass!

$ claude instance send-message --instance-id 2 --message "great! now with coverage please"

Use cases are infinite. Here are some:

  • connect to remote claudes for remote-control
  • have one claude node be the orchestrator driving other claudes as workers/resources
  • in general we could get a network of agents, that exchange tasks and knowledge in natural language
  • generalists vs specialists claudes: I could have a specialist claude run on my specific server answering to natural language requests, while a local generalist claude call it, having no clue of the specific API.

Currently I achieve a dumbed-down version of this using tmux send-keys and capture-pane, and now with hooks I'll try to expand with the Stop hook. (BTW, using tmux send-keys and capture-pane is a great way to have claude drive long-running commands, interactive commands, long runner REPLs, etc. in general, not just other claudes)

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗