Cyborgy CLI
cyborgy extends coding-agent CLIs such as Claude Code, Codex, and OpenCode with the
Cyborgy MCP, workspace roles, skills, memory, extension APIs, and temporary
tunnels.
This package provides:
cyborgy: the main CLI.cyborgy-mcp: the MCP server used by supported coding agents.cyborgy-devandcyborgy-mcp-dev: development-environment entry points.
The built-in profiles are authoritative: cyborgy uses production state in
~/.cyborgy, while cyborgy-dev uses development state in ~/.cyborgy-dev.
A stale saved URL for the other built-in environment is ignored. Set
CYBORGY_API_URL explicitly when intentionally targeting a custom endpoint.
Install
pip install cyborgy
For local Cyborgy development tooling:
pip install "cyborgy[dev]"
Basic usage
cyborgy login
cyborgy mcp install --target codex
cyborgy codex exec "summarize this repository"
cyborgy devin -- "review this repository"
cyborgy grok "fix the failing test"
Sending files to the user
Agents send user-facing files with the MCP tool send_file_to_user(path). The
file is delivered to the current session through the existing private View API
and appears under “Files from AI” in the Cyborgy web app. Returning a local path
or opening a local GUI does not deliver a file to a remote user. Files larger
than 25 MiB must be reduced or converted so the relevant part can be sent.
The old show_file(path) name remains as a deprecated alias and delegates to
the same delivery implementation. It will be retained until both at least two
subsequent minor CLI releases have shipped and all active workers are confirmed
updated; removal follows whichever milestone occurs later.
The CLI stores login state locally and resolves MCP/skills into user-owned runtime state outside the current repository. Agent wrappers are available for Claude Code, Codex, Cursor Agent, GitHub Copilot CLI, Devin CLI, and Grok Build.
Clean workspace runtime
Normal wrapper launches and sync/install commands do not create .claude,
.codex, .cursor, .copilot, .devin, .grok, .cyborgy, .mcp.json, or
plugins/ paths in the working tree. Persistent workspace settings use the XDG
data directory and generated plugins/configuration use the XDG cache directory:
${XDG_DATA_HOME:-~/.local/share}/cyborgy/<profile>/workspaces/<workspace-key>/
${XDG_CACHE_HOME:-~/.cache}/cyborgy/<profile>/workspaces/<workspace-key>/
CYBORGY_DATA_HOME and CYBORGY_CACHE_HOME override those roots. Worker
sessions receive a session-specific cache overlay so concurrent agents in the
same repository cannot replace each other's supervisor skills.
Runtime loading is target-specific:
- Claude Code, Cursor Agent, and Copilot receive an external
cyborgy-workspacebootstrap plugin through--plugin-dir. - Copilot also receives the external MCP file through
--additional-mcp-config. - Codex receives the skill catalog and MCP definition through session config
overrides while preserving existing
developer_instructions. - Devin receives an external declarative
--agent-config; an explicitly supplied JSON/YAML agent config is merged with it. - Grok receives the external skill catalog through
--rulesand uses an idempotent user-scoped MCP entry in~/.grok/config.toml.
To intentionally create native project files for Git management, opt in:
cyborgy mcp install --target claude --project-local
cyborgy skills install <skill-id> --target claude --project-local
cyborgy workspace sync --target claude --project-local
Existing project-local files from older Cyborgy versions are never deleted automatically because they may already be tracked or user-edited. After upgrading, review and remove those legacy generated paths manually if they are not meant to remain in Git.
Agent model catalogs
cyborgy models list reports the model catalogs exposed by installed local
agent CLIs. It prefers scriptable account-aware sources such as
cursor-agent models, codex debug models, grok models, and opencode models. Claude,
Copilot, and Devin use a bounded interactive /model probe when needed.
cyborgy models list
cyborgy models list --tool codex --json
cyborgy models list --no-fallback
cyborgy models list --no-interactive-probe
For tools that only expose account-specific choices through an interactive
model selector, the CLI uses a short-lived PTY probe, waits for the tool prompt,
answers terminal capability queries, and accepts rows only after the selector
is visible. Worker registration caches the same structured catalog for 15
minutes so the web model picker stays aligned with what the local tool can
actually show, including degraded/fallback source information.
Agent quota/usage reporting follows the same rule: Cyborgy parses structured
usage windows from short-lived interactive usage views when available, and
reports unknown instead of guessing when a tool does not expose parseable
limit, used, or remaining values.
Context rollover history
When a saved native conversation crosses its configured context threshold,
the worker starts a fresh native agent session and builds portable continuation
context from the authenticated Cyborgy session-event API. Production serves
that canonical history from BigQuery, so rollover does not depend on the next
agent sharing the previous tool, host, HOME, or transcript layout. The worker
flushes pending events, reads every history page, and retains both the first
user request and the latest turns in the compact context. A local absolute
transcript path remains only as a fallback when canonical history is
unavailable.
Worker auto-update
cyborgy worker start is the launcher form: it starts or verifies one
background worker for the current profile, worker name, and repository root,
then exits 0. A second cyborgy worker start for the same context is a no-op
when that worker PID is still alive; stale pid records are replaced safely.
Only the start, stop, and restart lifecycle actions are public. The worker
runtime is internal to the managed launcher; use cyborgy worker start for
normal operation.
cyborgy worker stop stops only the managed background worker recorded by
cyborgy worker start for the same profile, worker name, and repository root.
It does not search by process name; stale or unverified PID records are
cleared/refused without sending a signal.
cyborgy worker restart uses the same managed-worker safety checks, then starts
the worker again for that context.
Workers enable pip package auto-updates by default. Set the variable to 0,
false, or off only when an operator needs to disable them:
CYBORGY_WORKER_AUTO_UPDATE=0 cyborgy worker start
The worker periodically asks the Cyborgy backend for the latest
cyborgy package version. If a newer version exists, it runs python -m pip install --upgrade cyborgy in a waited subprocess. The Python is resolved from
CYBORGY_WORKER_PYTHON, the configured/current cyborgy executable's shebang,
the active pyenv Python when the executable is a pyenv shim, or the current
PATH before falling back to sys.executable. After a
successful install, the worker stops polling for new commands, lets any current
agent subprocess finish, and re-execs itself at the next idle boundary through
CYBORGY_WORKER_EXECUTABLE or the current PATH's cyborgy wrapper. It does
not broad-kill processes or interrupt running agent commands.
To keep a development-extra install on the same release track, start the worker
with CYBORGY_WORKER_AUTO_UPDATE_PACKAGE=cyborgy[dev]. Version checks still use
the cyborgy distribution reported by the Cyborgy backend, while pip upgrades the configured package
spec (cyborgy by default, or cyborgy[dev] when requested).
Optional knobs:
CYBORGY_WORKER_AUTO_UPDATE_INTERVAL: seconds between checks, default 300 (5 minutes), minimum 60.CYBORGY_WORKER_AUTO_UPDATE_INITIAL_DELAY: seconds before the first check.CYBORGY_WORKER_AUTO_UPDATE_TIMEOUT: seconds before the pip install attempt times out.CYBORGY_WORKER_AUTO_UPDATE_PACKAGE: pip package spec, defaultcyborgy.CYBORGY_WORKER_AUTO_UPDATE_INDEX_URL: pip index URL for installation.CYBORGY_WORKER_EXECUTABLE: explicitcyborgywrapper to use for worker re-exec.CYBORGY_WORKER_PYTHON: explicit Python interpreter to use for auto-update installs.
Status
This is an alpha package. The public CLI surface is expected to evolve with the Cyborgy service.
1 maintainer
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file cyborgy-0.1.67.tar.gz.
File metadata
- Download URL: cyborgy-0.1.67.tar.gz
- Upload date:
- Size: 172.6 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via:
twine/6.2.0 CPython/3.10.14
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
5bb806098cf2c8f54d9f6d62426c3b07ed5e365efed7280597019e724a79a8be
|
|
| MD5 |
ba57370a3af2f06b33c79723e0fce0e9
|
|
| BLAKE2b-256 |
a26cf7b26756ba37c51cecc55d0e16e87b53b63c3794280600802c8eeb190ebd
|
File details
Details for the file cyborgy-0.1.67-py3-none-any.whl.
File metadata
- Download URL: cyborgy-0.1.67-py3-none-any.whl
- Upload date:
- Size: 176.0 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via:
twine/6.2.0 CPython/3.10.14
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
835637f5ab8edad18aae98c493358a5b0072332747a83003e3b8f8e4df0d2575
|
|
| MD5 |
1acd91922670595c4074dd82ac1152e8
|
|
| BLAKE2b-256 |
f4116ee2d7ce41b7d8caf168b1088f5ca0c576446c98875a611ece66063ce85d
|
