@meego-harness/codem-worker

Standalone CodeM CLI worker bridge for meego-harness.

For most users, prefer @meego-harness/worker-cli as the main entrypoint and let it install or manage this package. This package still supports direct standalone use.

It logs into a WorkerServerSDK endpoint as a normal worker, executes tasks through the local codem CLI, and reuses one CodeM session per harness contextId.

Commands

meego-codem-worker setup
meego-codem-worker setup --json --server-url ws://127.0.0.1:3000/workers --email [email protected] --worker codem-worker-1 --capability-summary "Handles TypeScript work" --workspace /path/to/workspace --permission-preset default --profile use-codem-default --model use-codem-default --reasoning-effort high
meego-codem-worker list --json
meego-codem-worker doctor --json
meego-codem-worker start --worker <workerId> [--tmux] [--codem-shell]
meego-codem-worker stop --worker <workerId>
meego-codem-worker stop-all
meego-codem-worker enable --worker <workerId>
meego-codem-worker disable --worker <workerId>
meego-codem-worker uninstall --worker <workerId>

Use --codem-shell when codem is only available through the user's interactive shell configuration.

Setup Inputs

setup persists one local worker config. Non-interactive setup accepts:

meego-codem-worker setup \
  --server-url ws://127.0.0.1:3000/workers \
  --email [email protected] \
  --worker codem-worker-1 \
  --capability-summary "Handles TypeScript work" \
  --workspace /path/to/workspace \
  --permission-preset default \
  --profile use-codem-default \
  --model use-codem-default \
  --reasoning-effort high

The prompt flow asks for:

| Prompt | Required | What to enter | | --- | --- | --- | | Worker Server URL | Yes | Websocket worker endpoint, for example ws://127.0.0.1:3000/workers | | Worker Email | Yes | Stable worker identity email | | Worker ID | Yes | Stable worker id, for example codem-worker-1 | | Capability Summary | Yes | Short summary shown to managers and dashboard | | Default Workspace | Yes | Existing absolute directory path | | Default Permission Mode | Yes | safe, default, or full-access | | Default Profile | Yes | use-codem-default or a specific CodeM profile name | | Default Model | Yes | use-codem-default or a pinned provider/model id | | Default Reasoning Effort | Yes | use-codem-default, low, medium, or high | | Add a repo mapping? | Optional | Whether to pin specific repo names to specific absolute directories |

Runtime Contract

The worker runs CodeM in headless SSE mode:

codem -p "<prompt>" --session "<sessionId>" --sse --no-memory-update [flags...]

Permission presets map to CodeM flags like this:

| Preset | CodeM flags | | --- | --- | | safe | --sandbox read-only --approval-policy never | | default | --sandbox workspace-write | | full-access | --yolo |

doctor verifies:

1. codem --help
2. codem tasks --help
3. codem sessions --help
4. One fixed-session -p --sse run plus one resume run in a temporary workspace

Task Metadata

The worker reads these optional metadata keys on first use of a contextId:

| Key | Type | Description | | --- | --- | --- | | repo | string | Repository directory under the configured workspace or an explicit repo mapping | | codemReasoningEffort | string | One of low, medium, or high | | codemPlanMode | boolean | Enables CodeM --plan for the first turn in that context and prepends the planning preamble |

Once a context is bound, later conflicting repo or reasoning metadata for the same contextId is ignored.

Operational Notes

• The worker server treats this bridge as a normal worker.
• One CodeM session is reused per harness contextId.
• Task cancellation aborts the in-flight CodeM process.
• Repo routing follows the same rules as codex-worker: absent repo uses the default workspace, empty mappings infer <workspace>/<repo>, and non-empty mappings require an explicit match.
• Structured project-node writes, attachment staging, and manager-run prompts reuse the shared harness protocols from the other CLI workers.