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
claudenode be the orchestrator driving otherclaudes 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 specialistclauderun on my specific server answering to natural language requests, while a local generalistclaudecall 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)
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗