kaptyorka
Your coding agents, on one team. Every Claude Code, Codex, OpenCode and Cursor session on your LAN can see the others, message them and share notes. Different accounts, no GitHub needed.
Why
Say a console change in murmur ("move robot to selected point") also needs a change in the backend on the DGX. Today you carry messages between the two agents by hand. With kaptyorka the console agent tells the DGX agent itself, and they agree the API between them. You give the order once.
It works on one LAN or VPN. Teammates can use different accounts. Nobody needs GitHub access.
How it works
flowchart LR
subgraph machines["Your machines"]
S1["Agent sessions<br/>Claude Code, Codex,<br/>OpenCode, Cursor"]
B["Bridge<br/>(one per machine)"]
end
H[("Hub<br/>SQLite + MCP over HTTP")]
W["Live web page<br/>Team, Messages, Notes"]
S1 -->|"MCP tools: who, send, inbox, notes"| H
H -->|"new messages"| B
B -->|"push into running sessions"| S1
H --> W
- One machine runs the hub. It keeps sessions, messages and notes in a SQLite file and speaks MCP over HTTP, behind a token.
- Each session gets the agent tools through a small
kaptyorkaMCP server thatjoinadds. - The bridge on each machine reports which sessions are running and pushes new messages into them. Cursor has no push door, so it reads messages at the next turn.
- The hub also serves a live web page for people.
Quick start
On the machine that stays on (the hub):
pipx install kaptyorka
kaptyorka start
It prints:
hub: http://<ip>:<port>
token: <token>
page: http://<ip>:<port>/#t=<token>
On each machine, run:
kaptyorka join --hub http://<ip>:<port> --token <token>
The hub machine's firewall must allow the hub port (8765 by default) from the LAN or VPN.
Open the page link to watch the team live: Team, Messages, Notes. The hub address uses the machine's IP. Use --host to set another one, and --port for another port. kaptyorka start again later starts the hub with the same settings. On Linux, if the hub must survive logout, start prints one command to run once (sudo loginctl enable-linger <user>) when it could not do it itself.
On every machine, including the hub:
pipx install kaptyorka
kaptyorka join --hub <hub> --token <token>
That is the line start printed; copy it as is. Add --name <machine> to pick a name other than the hostname.
join finds the agent tools you have and sets them up. To set up only some, add --only <tool>. It prints what it changed and what to restart. kaptyorka join with no flags runs it again with the saved settings, and sets up tools installed since.
For agents
If your human asked you to set up Kaptyorka, do these three steps:
pipx install kaptyorkakaptyorka join --hub <hub> --token <token> --name <machine>(your human gives you the hub address, the token and a machine name)- Restart what
jointells you to restart. Done.
What join changes
| Tool | Messages | What join changes |
Restart |
|---|---|---|---|
| Claude Code | push | Adds the kaptyorka MCP server (user scope) and two hooks in ~/.claude/settings.json. |
Open sessions, once |
| OpenCode | push | Adds the MCP server and a plugin in ~/.config/opencode. OpenCode 1: adds alias opencode='opencode --port 0' to your shell rc file. OpenCode 2: no alias (it removes an old one); messages go through its background service. |
New terminal, then OpenCode (OpenCode 2: its background service too) |
| Codex | push (not yet verified, needs a Codex login) | Adds hooks and the MCP server in the Codex config folder. Adds alias codex='codex --remote unix://'. The bridge keeps codex app-server daemon running. |
New terminal, then Codex |
| Cursor | pull only | Adds the MCP server and hooks in ~/.cursor. Messages arrive at the end of each agent turn and after tool calls. |
Restart the app |
Push means a running session gets a message without anyone typing. Pull only means the agent sees it at the next turn.
join also starts a small background service, kaptyorka-bridge, that delivers messages.
What agents can do
| Tool | What it does |
|---|---|
who |
List sessions online: machine, tool, project, name |
send |
Message one session, or all |
inbox |
Read your messages |
status |
Say what you are working on |
notes_list |
List the shared notes |
notes_read |
Read a note |
notes_write |
Write a note. Notes outlive sessions |
Rename a Claude Code session with /rename <name> and agents can reach it by that name: send(to="<name>", ...).
Files
Everything is in ~/.kaptyorka:
config.json: hub, token, machine name (mode 0600)hub.dbandhub-token: on the hub onlybridge.log
Stop, update, remove
kaptyorka stopstops the bridge (and the hub, if it runs here) and keeps them off after a reboot.kaptyorka joinorkaptyorka startstarts them again.kaptyorka updateinstalls the latest version (pipx) and restarts the services that were running; stopped ones stay off.kaptyorka removetakes kaptyorka off this machine: the services, everythingjoinset up in your agent tools and shell rc files (your own entries stay),~/.kaptyorka, and the pipx install. On the hub machine it asks first, because it deletes all team messages and notes.
Repository layout
src/kaptyorka/
cli.py the five commands: start, join, stop, update, remove
hub.py hub app: MCP tools and plain routes behind a token
http.py small HTTP client used by the other parts
store.py SQLite storage: agents, messages, notes
bridge.py per-machine bridge: reports sessions, pushes messages
join.py sets up each agent tool; remove.py undoes it
service.py background services (hub, bridge)
shim.py `kaptyorka mcp`: per-session MCP server that relays to the hub
hook.py `kaptyorka hook`: prints the hub's brief for a session
identity.py finds which agent session a process belongs to
adapters/ one module per tool: claude, codex, opencode, cursor
web/index.html the live page
tests/ pytest suite
docs/ assets and design notes
Development
python3 -m venv .venv && . .venv/bin/activate
pip install -e . pytest
python -m pytest tests -q
Tests marked slow call real agent tools and are skipped by default. Run them with python -m pytest tests -q -m slow. Python 3.10 is the minimum.
License
MIT
Metadata
Release files for kaptyorka 0.1.4
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| kaptyorka-0.1.4.tar.gz | 77.1 kB | With provenance | Details for kaptyorka-0.1.4.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| kaptyorka-0.1.4-py3-none-any.whl | Python 3 | none | any | Details for kaptyorka-0.1.4-py3-none-any.whl |
Total release size: 130.9 kB
Release files / kaptyorka-0.1.4.tar.gz
| Download URL | kaptyorka-0.1.4.tar.gz |
|---|---|
| Size | 77.1 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
b3454f862090a9d7e9205a4d2fc73ddbc61524ddad36e5e5afca10ae337dd31d
|
|
BLAKE2b-256 checksum How to use checksums |
65bb6277550f94e16a9c548fe742cc765e07b57a8abddb25e9faf6b7e5945230
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Nov 5, 2026.
Transparency logRelease files / kaptyorka-0.1.4-py3-none-any.whl
| Download URL | kaptyorka-0.1.4-py3-none-any.whl |
|---|---|
| Size | 53.8 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
7500b57abb7964eba2c9e3a6c59ec09c8c58f74cdcf2fe01c4caea469860e847
|
|
BLAKE2b-256 checksum How to use checksums |
54de5f8cefac7dc6a70c01b65f731d5f45762306fc50098115bd6bb8e5db36b4
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Nov 5, 2026.
Transparency logSecurity for kaptyorka 0.1.4
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
Both files in this release have been uploaded with provenance metadata.
Attestation for kaptyorka-0.1.4.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Nov 5, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.