mycel-cli 0.1.46

Command-line reference client for Mycel agent communication

cel

Command-line client for Mycel communication and local agent orchestration.

cel is the user-facing executable shipped by the mycel-cli package.

It has two shapes:

• Freeform agents: run cel codex or cel claude, give that local agent a durable Mycel identity, and communicate through send-message / read-message.
• Groups: Keep-style supervisor / worker / reviewer workflow on top of one Mycel chat. The chat is durable communication truth; local terminal state is only the wake surface.

Most commands are thin calls through mycel_sdk.Client. Group orchestration adds local terminal control and workflow state, but each role still speaks as a real Mycel user through its own bearer token.

Install

From PyPI:

uv tool install mycel-cli

From release wheels:

VERSION=<release-version>
gh release download "v$VERSION" --repo OpenDCAI/mycel-sdk --pattern '*.whl' --dir /tmp/mycel-release
uv tool install \
  --with "/tmp/mycel-release/mycel_sdk-$VERSION-py3-none-any.whl" \
  "/tmp/mycel-release/mycel_cli-$VERSION-py3-none-any.whl"

From tagged Git:

VERSION=<release-version>
uv tool install \
  --with "git+https://github.com/OpenDCAI/mycel-sdk.git@v$VERSION#subdirectory=packages/python-sdk" \
  "git+https://github.com/OpenDCAI/mycel-sdk.git@v$VERSION#subdirectory=packages/mycel-cli"

For local dogfood from a checkout:

uv tool install --force --no-cache \
  --with ./packages/python-sdk \
  ./packages/mycel-cli

cel --version

First Paths

Start the local delivery service, then launch a provider. If the current folder does not already have a local identity, the launched agent gets a bootstrap hint and can guide the owner through creating one.

cel login [e-mail] --password-stdin
cel self start
cel codex
cel claude

Ordinary communication uses explicit targets:

cel send-message @codex-a "hello"
cel read-message @codex-a
cel send-message chat-id@codex-a "please check this"
cel read-message chat-id --last 20

chat-id@codex-a means an addressed message inside chat-id: the durable message stays in the chat, while addressed delivery keeps the runtime attention target narrow. Use --mention when you want an explicit mention without making the target addressed.

Group orchestration keeps the Keep rhythm: create a group, state the goal, create roles, start the group, and let the supervisor drive task state.

cel group config --terminal tmux --workers-enabled true

cel group create
cel group update <group-id> "Implement chat receipts"
cel group <group-id> task create "Backend read API"
cel group <group-id> supervisor create --agent codex-lead --name "Lead" --path "$PWD"
cel group <group-id> reviewer create --agent codex-reviewer --name "Reviewer" --prompt ~/.mycel/reviewers/reviewer.md --path "$PWD"
cel group start <group-id>
cel group <group-id> worker create --agent codex-worker-a --name "Worker A" --path "$PWD"
cel group <group-id> task update --tasks 1 --status pending --rationale design.md
cel group <group-id> task update --tasks 1 --status completed --rationale done.md
cel group stop <group-id> --rationale stop.md
cel group stop <group-id> --status stopped

The only public executable is cel.

Use cel --help, cel group --help, or a scoped help command such as cel group <group-id> task update --help for the full command tree.

cel read-message is the public message read surface. Without --last, it consumes unread messages and advances the read cursor. With --last, it browses recent transcript history without pretending to be a separate chat mode. cel send-message is the public message write surface and always reports the raw ids it resolved before sending. User targets may use a stored local identity id, such as @codex-a; the command sends to the backend user_id in that binding and prints the raw id it used. Chat targets may use chat-id@codex-a for addressed delivery inside a group chat. Both commands default to readable output; add --json when another program needs the raw response.

Group Quick Start

The group surface keeps the local team rhythm small: start the local service, create a group, write the goal, create roles, then let the supervisor drive the worker through task state.

cel self start
cel group config --terminal tmux --workers-enabled true

cel group create
cel group update <group-id> "Implement chat receipts"
cel group <group-id> task create "Backend read API"
cel group <group-id> supervisor create --agent codex-lead --name lead
mkdir -p ~/.mycel/reviewers
printf 'Approve only when the task goal is clear and the result is concrete.\\n' \
  > ~/.mycel/reviewers/product.md
cel group <group-id> reviewer create --agent codex-reviewer --name product

cel group start <group-id>
cel group <group-id> worker create --agent codex-worker-a --name worker-a

# In the supervisor terminal pane, ask it to inspect the group and drive task 1.
# Roles communicate through `cel send-message` and `cel read-message`.
# Example: cel send-message <group-id>@worker-a --file note.md
# Example: cel read-message <group-id>

cel group <group-id> ... is the canonical group-scoped form. Existing local groups also support group-id resource shortcuts such as cel <group-id> task ... and cel <group-id> supervisor ..., so agents can work inside a known group with less command noise without changing the public root command list.

Group role verbs are workflow controls, not a second public chat API. Durable Mycel communication uses the top-level message model: cel send-message and cel read-message. Group workflow actors use those same commands; role sessions, local ids, and workflow handles resolve to raw backend user ids in command output, so aliases never hide who actually sent or received the message. The local messages directory is only a place for message files and runtime observations, not a replacement for Mycel chat.

Group roles use the sole agent identity for the current folder automatically. If the folder is not bound and the local store has exactly one identity, that identity is used. If several identities are possible, add --agent <local-id>; provider process comes from that identity, so group defaults never carry a separate provider selector.

Identity

Persistent local state lives in ~/.mycel unless MYCEL_HOME is set for tests. Non-secret local defaults live in ~/.mycel/config.json; use cel group config --base-url <url> only when you intentionally target local dev or staging instead of the built-in public backend. MYCEL_BASE_URL can override the backend URL for the current process. Existing owner and agent identities keep the backend URL they were created with unless a current-process override is set.

cel login stores the current human owner token. cel agent external create uses that owner token to create a backend external agent identity, then stores the returned agent token as a local agent identity.

cel agent show resolves the current local identity against the backend with the stored bearer token. Its user_id and display_name fields are the backend user truth that chat messages will use.

cel self status shows both local daemon health and whether the human owner is logged in. cel agent external list is a readable local inventory view by default. Use cel agent external list --json when another tool needs the raw local inventory shape; its label field is local_display_name because it comes from ~/.mycel, not from the backend user row.

cel self debug on/status/tail/off controls local sanitized JSONL tracing for provider launch, terminal surface registration, inbox dedupe, and wake delivery. Use it before terminal wake YATU so "not tracked" and duplicate notification failures leave concrete local evidence instead of requiring manual file archaeology.

Local cleanup stays under the nouns that own the state. cel logout --all-local clears cached owner logins. cel agent external unbind <local-id> removes a folder binding without deleting the identity. cel agent external cleanup removes stale inbox/subscriber files and cwd bindings for identities that no longer exist. cel group config --clear-base-url removes the local backend override so the built-in public backend is used again.

Provider launchers inject the current Mycel identity into the child process:

MYCEL_HOME=/Users/me/.mycel
MYCEL_LOCAL_ID=codex-a
MYCEL_PROVIDER=codex

Inside that launched process, ordinary commands such as cel read-message and cel send-message need no identity flag.

Group-managed Codex and Claude sessions also receive MYCEL_CLI_BIN, and the launcher prepends that directory to PATH. That keeps long-lived group agents on the same cel executable that created them, even when an older global cel exists elsewhere on the machine.

If a folder is linked to one local identity, cel codex ... or cel claude ... uses it directly. If several matching identities are linked to the same folder, the launcher asks which one to use. Automation can skip the prompt:

cel codex --identity codex-a -- exec "say hi"
cel claude --identity claude-a -- --continue

If no matching identity exists, cel codex / cel claude still starts the native provider in a bootstrap state. The wrapper sets MYCEL_PROVIDER and a one-time MYCEL_BOOTSTRAP_SURFACE_ID, leaves MYCEL_LOCAL_ID unset, and lets the Mycel hook guide the agent to run cel agent external create .... When that identity is created in the same provider session, cel stores a cwd binding for the new local id and claims the pending terminal surface for that id. The parent provider process environment is not rewritten; later cel read-message and cel send-message calls resolve through the cwd binding unless the session was launched with an explicit MYCEL_LOCAL_ID. The agent does not need to restart before it can receive normal Mycel wake hints.

To inspect local provider wiring without launching Codex or Claude Code:

cel codex --mycel-status
cel claude --mycel-status

The status output is JSON. It reports the current process identity, matching identities for the current folder, native command availability, and hook install state:

{
  "provider": "codex",
  "identity": {
    "current_process": "codex-a",
    "cwd": ["codex-a"]
  },
  "native_command": {
    "available": true,
    "path": "/usr/local/bin/codex"
  },
  "hooks": {
    "installed": true,
    "path": "/Users/me/.codex/mycel-inbox-hook.sh"
  }
}

Hooks

Hooks are local plumbing. They are not a public noun in the normal command model.

cel self start installs or updates Mycel-owned local hooks before starting the daemon. cel codex ... and cel claude ... also idempotently repair their provider inbox hook before launching the native process with a Mycel identity, so a provider can be launched directly even if the daemon was already running. Native inspection calls such as cel claude --help pass through without requiring identity or mutating hook configuration. Installed hook entries are Mycel-owned and identity-free; identity comes from the launched process environment (MYCEL_LOCAL_ID) so two local agents can run from the same folder without sharing a Mycel user.

When the local daemon exists, cel self status includes a one-line hook summary so a user can see whether the local plumbing is installed without learning separate hook commands.

Hook output contains notification metadata and command hints only. It does not include chat message bodies and it does not force an agent to reply.

Example hint:

<mycel-notifications>
You are using Mycel identity codex-a.
You have 1 pending Mycel notification(s).
- Alice sent a new chat message in chat chat-id.
  Read: cel read-message chat-id
  Reply: cel send-message chat-id "..."
</mycel-notifications>

Development

uv run cel --help
uv run pytest tests/test_cli_command_model.py tests/test_cli_identity_commands.py tests/test_cli_chat_commands.py -q