CLI Injection
Workspaces are CLI-first. The launcher does not inject an .mcp.json by default. Instead, it puts OpenAlice's domain CLIs on the agent's PATH, then injects short playbook skills that teach the agent how to use them.
This keeps the model loop native. Claude Code, Codex, opencode, and other CLIs keep their own prompt cache, terminal rendering, config files, and session behavior. OpenAlice only supplies the repo and tool surface.
The injected binaries
| Binary | For | Command groups |
|---|---|---|
alice | This workspace's research surface | rss, market, analysis, think |
alice-workspace | Collaboration, provenance, and work tracking | inbox, peer, track, issue, signature, provenance, conversation |
traderhub | Low-frequency Data Hub | board, equity, etf, economy, global, shipping, fed, crypto, index |
alice-uta | Beta trading layer | account, contract, order, position, git, market, sim |
alice market search --query AAPL
alice rss grep --pattern "rate cut"
traderhub board get --board macro
alice-workspace track add --name "NVDA supply chain"
alice-workspace signature show
alice-workspace inbox ask --id <entryId> --prompt "Why did you send this?" --await
alice-uta order place --alice-id alpaca-paper:AAPL --side buy --qty 10
Trading commands can stage intent, but execution still flows through Trading as Git: stage, commit, then push. Push waits for Web UI approval by default; Pro mode can explicitly delegate it to the AI.
Workspace identity
Every injected CLI call is scoped through the workspace gateway. The binary knows which workspace it belongs to through the launch environment, and the server receives calls through a /cli/<wsId> boundary.
That identity matters:
- A workspace cannot mislabel another workspace's Inbox entries.
- Tracked entities and issues can be attributed to the workspace that wrote them.
- Peer access is explicit:
alice-workspace peer path --id <wsId>resolves another workspace only when the caller has a workspace id from an Inbox entry or related surface. - A Session receives an OpenAlice-owned
resumeId, used for signatures, provenance, exact follow-up, and headless-to-interactive continuation. Native CLI session ids stay behind the backend boundary.
Guidance layers
OpenAlice keeps always-loaded instructions short. Durable behavior lives in CLAUDE.md and AGENTS.md; changing command manuals and examples live in discoverable skills; the live CLI manifest and validation errors are the final authority.
One concept has one primary skill owner:
| Concept | Skill |
|---|---|
| Inbox, Issue collaboration, provenance, peer questions | alice-workspace |
| Issue file shape, ownership, schedules, headless delivery | self-scheduling |
| Low-frequency market and fundamental data | traderhub |
| K-line analysis and source choice | alice-analysis |
| Broker state and trading writes | alice-uta |
This avoids copying a volatile flag manual into every Workspace prompt. When a Workspace carries an older skill snapshot, the live CLI should reject stale syntax with a boundary-aware error and point to the current command.
Skills vs MCP
The injected playbook skills are documentation for the agent, not a separate runtime server. They teach command syntax, boundaries, and safety rules. The actual operations happen through local binaries on PATH.
Claude Code reads its copy from .claude/skills/. Codex and current Pi share
the canonical .agents/skills/ copy; Pi's separate .pi-agent/ directory
holds provider/model state, not a second OpenAlice skill tree.
One skill is always injected: self-scheduling. It teaches the .alice/issues/<id>.md format so every workspace can create or update a scheduled issue, even if the template opts out of the broader alice* tool playbooks.
Why this design
- Native CLI behavior stays intact. OpenAlice does not need to normalize every agent vendor's event stream.
- The surface is inspectable. The agent runs commands a human can run too.
- The contract is narrow. The launcher owns PATH injection and identity; each CLI owns its domain.
- Tools are repo-friendly. Output can become files, commits, issues, or Inbox entries inside the same workspace.
Next Steps
- Settings Injection - See how instructions, credentials, and skills get written.
- Sessions & Collaboration - Learn how
resumeId, signatures, and peer questions work. - Self-Describing Issues - See the issue format every workspace can use.
- Workspaces - See how sessions are created and resumed.