Command Line (CLI)

What it is

qoderwake is QoderWake's local command-line tool plus a resident daemon. It starts a local daemon that manages digital employees (Wakers), projects, sessions, IM channels, scheduled tasks, memory, and more, and serves a local Web Console. The CLI itself is a thin client of the daemon: the vast majority of commands simply forward requests to the local daemon's HTTP API. Basic form

qoderwake [options] [command]

Global option	Description
`-v, --version`	Print the version
`-h, --help`	Print help; append `--help` to any subcommand to see its usage

Quick start

Install the CLI before first use. On macOS / Linux, use the one-line command-line install:

curl -fsSL https://qoder-ide.oss-ap-southeast-1.aliyuncs.com/qoderwake/install.sh | bash

For the macOS package and the Windows installer, download from the QoderWake website; see Quick start for full installation instructions. If qoderwake is not found, reopen the terminal, or use the full path ~/.qoderwake/bin/qoderwake. After installation:

# 1) Check version and platform
qoderwake version            # => qoderwake 1.0.3 (darwin/arm64)

# 2) Log in (browser login by default)
qoderwake login              # --method browser|token|file
qoderwake whoami             # Show the currently logged-in user

# 3) Start the daemon (resident, in the background)
qoderwake start              # Listens on 127.0.0.1:19820 by default
qoderwake status             # Show daemon / device / session / scheduled-task status

# 4) Open the local Console
qoderwake portal             # Open the Console in the default browser
qoderwake portal --print-url # Print the URL only

# 5) Stop / restart
qoderwake restart
qoderwake stop

Tip: status returns structured JSON containing device (device online status), sessions (total / running), agents (number of local Wakers), and tasks (internal cron task health).

Core concept model

Understanding these objects and their hierarchy is a prerequisite for using the CLI well.

User (currently logged-in user)
 └─ Waker (digital employee, id: ag_...)     ← formerly worker/agent; the --worker-id alias is retained
     ├─ Project (a repo / workspace binding)   ← there are also "public projects", which belong to no Waker
     │   └─ Session (a single run, id: sess_)  → artifacts / trace
     ├─ MCP Server (external tool integration)
     ├─ Skill (capability pack, git-versioned)
     ├─ Memory (agent-scoped long-term memory)
     └─ Permission (tool / file / builtin-tools / model-security four-section guard)

Conversation (conversation kernel, convId + kind)  → Messages → Runs → Attachments
 ├─ Group (group-conversation container) → Group Conversation → Thread
 └─ Channel (IM channel, a single-conversation constrained form) → Pairing (external IM identity pairing)

Automation (schedule / pull trigger, id: tr_) → Run (rn_) → Trace (task lifecycle observability)

Team (temporary team within a project) → Mission (task lifecycle) → RoleRun (member execution record)

SOP (collaboration procedure): profile (catalog identity) → release (immutable version) → template (editable white-box JSON)

Item by item

Waker (digital employee): the core entity, id prefix ag_. Historically called worker / agent; the command worker is a hidden alias of waker, and --worker-id / --agent-id are compatibility aliases of --waker-id. A Waker owns its own projects, MCP, Skills, memory, and permissions.
Project: a code repository or workspace binding. Two kinds: Waker-private projects (require --waker-id) and public projects (--public, belonging to no Waker). project onboard clones/symlinks the repo and runs an initial analysis to seed project memory.
Session (a run): a single run unit of a Waker, id prefix sess_. The isolation dimension = Waker + workspace + sessionId. It produces artifacts, file changes, and an event stream.
Conversation (conversation kernel, convId): the next-generation unified communication/execution node, identified by conversation_id + kind (default / group_conversation / group_thread). It carries messages, delivery, runs, and attachments. The messages and runs commands operate on it.
Group: a container holding multiple group conversations; a Thread can be derived from a message. channel is the "single-conversation constrained" form of a group.
Run / Task: a Run is one execution frame of a conversation (runs list/cancel); a Task is a lifecycle work unit tracked by a Trace.
Trace: links trace_id → agent_id / session_id / task_id / run_id together and computes queue / dispatch / execution / total durations. It is the cross-object observability connector.
Automation: a task triggered on a schedule (cron) or once (timestamp), id prefix tr_; the legacy command name is trigger. A single execution is one rn_ run.
Channel (IM channel): an inbound IM binding for DingTalk / Lark / WeChat, etc. Pairing is the channel-user pairing handshake, with an approval flow.
SOP (Standard Operating Procedure): a collaboration skill with skill_kind=sop, in a three-layer structure — profile (stable catalog identity), release (immutable, with version and summary), template (editable white-box qoder-sop-template/v1 JSON). It can be bound to a group in order.
Skill / MCP / Plugin / Extension: a Skill is a Waker capability pack (git-versioned, diff/rollback-able); MCP is a per-Waker external tool server; a Plugin is an in-process trigger/event-source plugin; an Extension is the local qodercli extension runtime manifest (read-only).
Memory: two scopes — agent (a Waker's long-term memory) and project (requires --project-id). Supports preview (dream), snapshot, diff, rollback, import/export.
Teams / Mission / RoleRun: a Team is a temporary member set within a project; a Mission is the authoritative task lifecycle entity; a RoleRun is a member's execution record under a specific committed plan version. teams diagnose produces a read-only diagnosis.

Global conventions and common options

Most commands share a set of common options; learn them once and reuse everywhere:

Option	Meaning
`--waker-id <id>`	Specify the digital employee. Required for most commands when omitted; `--worker-id` / `--agent-id` are compatibility aliases
`--format <table\|json>`	Output format, default `table`; some commands support only `json`/`text`/`markdown`
`--json`	Output raw JSON directly, equivalent to `--format json`, suitable for scripting
`--file <path>` / `--json-file <path>`	Read long text or JSON input from a file to avoid shell escaping
`--dry-run` / no `-y, --yes`	Write operations show a preview/diff first, and only persist once a confirmation flag is added
`--project-id <id>`	Specify the project for project-scoped operations

Conventions:

Every command supports -h, --help; the options in this manual come from each command's --help.
Destructive/write operations (template update/rollback/delete, memory rollback/import, etc.) only preview by default; you must explicitly add -y/--yes/--apply to execute.
The CLI is only a thin client of the daemon; run qoderwake start to bring up the daemon before running most commands.

Daemon management

start — start the daemon

qoderwake start [options]

Option	Description
`--host <host>`	Listen address. Local loopback only by default; specifying a public address triggers an external-exposure confirmation
`--port <port>`	Listen port or `auto`, default `19820` (CN region default 19830)
`--foreground`	Run in the foreground (no detach), convenient for watching logs
`--open`	Open the browser Console after starting
`--no-keepalive`	Start a detached daemon but do not register an OS-level keepalive service
`--mock`	Use the embedded mock gateway, no login required (`--foreground` only), for local trial/debugging
`-y, --yes`	Non-interactively confirm external exposure

stop / restart

qoderwake stop [--force] [--no-keepalive]      # --force uses SIGKILL to force-kill
qoderwake restart [--host ...] [--port ...] [--foreground] [--no-keepalive] [--force] [-y]

restart options are basically the same as start; --force is used to confirm the "the replacement instance is available locally only" scenario.

status — daemon status

qoderwake status

Returns structured JSON; key fields: device (device online status), sessions (total / running), agents (number of local Wakers), tasks (internal cron task health).

portal — open the local Console

qoderwake portal              # Open the default browser
qoderwake portal --no-open    # Print the URL only, do not launch the browser
qoderwake portal --print-url  # Open and also print the URL to stdout

Authentication and account

qoderwake login [--method browser|token|file] [--token-file <path>]

Option	Description
`--method <method>`	Login method: `browser` (default, browser authorization), `token` (interactively paste a PAT), `file` (read a PAT from a file)
`--token-file <path>`	File path to read the personal access token (PAT) from when `--method file`
`--qoder-cli-path` / `--qodercli-path`	Legacy no-op; browser login is now hosted by qoderwake itself

logout / whoami

qoderwake logout    # Clear local credentials
qoderwake whoami    # Print the current user: Name / Email / User ID / login method

Configuration and storage

qoderwake has three independent config stores: config (daemon app config, config.json), settings (user preferences, settings.json), and permission (each Waker's four-section permissions, see the Permission section).

config — daemon app config

qoderwake config list              # List all config
qoderwake config get <key>         # Read one item
qoderwake config set <key> <value> # Write one item
qoderwake config reset             # Restore defaults

settings — user preferences

qoderwake settings init [--storage sqlite|file] [--quiet]  # Initialize settings.json
qoderwake settings get [key]                              # Read (omit key to read all)
qoderwake settings set <key> <value>                      # Write

settings init --storage selects the storage backend: sqlite (default) or file.

storage — storage backend migration

qoderwake storage migrate --from <backend> --to <backend> [--switch]

Option	Description
`--from <backend>`	Source backend: `sqlite` or `file`
`--to <backend>`	Target backend: `sqlite` or `file`
`--switch`	After a successful migration, automatically switch `settings.storage.backend` to the target backend

Migration has "copy" semantics: without --switch it only copies data and does not change the current backend.

backup — pre-upgrade backups

qoderwake backup list                 # List automatic pre-upgrade backups
qoderwake backup restore <backup-id>  # Restore a specific backup (the daemon must be stopped first)

Always run qoderwake stop before restoring; otherwise it will fail because the daemon holds the storage.

Waker (digital employee)

Basic CRUD

qoderwake waker list [--json]                 # List local Wakers
qoderwake waker get --waker-id <id>           # View one
qoderwake waker create [options]              # Create
qoderwake waker delete --waker-id <id>        # Delete
qoderwake waker export [options]              # Export to a zip

Key create options: --template-id / --template-json <path> / --template-zip <path> (pick one as the template source), --name, --description, --workspace <path> (omit to use the daemon-hosted workspace), --session-timeout <seconds>. Key export options: --out <path> writes to a file; --full exports everything (projects/triggers/memory/connectors/permissions); --include-secrets includes sensitive env and tokens; --include-runs includes trigger run history. Omitting both --waker-id and --full exports all Wakers.

waker update — update by field

qoderwake waker update <field> [value] --waker-id <id> [--file <path>] [--append]

Updatable fields: name, description, avatar, coreCapabilities, workStyles, deliveryCommitments, skill, mcp, identity, persona, bible.

List/JSON fields (coreCapabilities/workStyles/deliveryCommitments/skill/mcp) support --append to append instead of overwrite.
Text fields (identity/persona/bible) also support --append; use --file to read from a file.
For avatar, --file is an image file path.

waker template — private templates

Solidify a mature Waker into a reusable, versioned private template:

qoderwake waker template list [--mine] [--lang en|zh]      # Preset templates or (--mine) your own private templates
qoderwake waker template save <wakerId> --name <name>      # Save as a private template
qoderwake waker template show <templateId> [--version <n>] # View a snapshot
qoderwake waker template versions <templateId>             # List versions
qoderwake waker template instantiate <templateId> --name <name>  # Create a Waker from a template
qoderwake waker template update <templateId> --from <wakerId> -y # Write a Waker back to the template
qoderwake waker template rollback <templateId> --version <n> -y  # Roll back to a version
qoderwake waker template delete <templateId> -y                  # Delete

Notes:

save supports --dry-run to preview the snapshot / stripped fields / quota, and --idempotency-key for retry safety.
update / rollback / delete only print the diff/plan by default; add -y, --yes to actually write.
--page / --page-size pagination is available only with list --mine.

Projects (project)

Projects come in two kinds: Waker-private projects (require --waker-id) and public projects (--public, belonging to no Waker).

qoderwake project list --waker-id <id> [--include-public] [--public]
qoderwake project create --waker-id <id> [options]
qoderwake project get --waker-id <id> --project-id <pid>
qoderwake project update --waker-id <id> --project-id <pid> [options]
qoderwake project delete --waker-id <id> --project-id <pid>
qoderwake project onboard --waker-id <id> --project-id <pid>

Shared create / update options:

Option	Description
`--public`	Target a public project (without a waker)
`--name` / `--description`	Project name / description
`--path <path>`	Filesystem source path
`--git-url <url>`	Git repository URL
`--local-path <path>`	Local path of the git source
`--label <label>`	Context source label
`--initializer-command <cmd>`	Initialization shell command
`--initializer-timeout <s>`	Initialization timeout (seconds)

list can use --include-public to merge public projects into the Waker's project list, and --include-public-scope used|all controls whether to include only used or all.
onboard clones/symlinks the repo and runs an initial analysis to seed project memory.
All project commands are compatible with the legacy --worker-id alias.

MCP (external tool integration)

Each Waker can mount several MCP Servers (stdio / http / sse transports).

qoderwake mcp list --waker-id <id>
qoderwake mcp get --waker-id <id> --mcp-id <mid>
qoderwake mcp add --waker-id <id> [options]      # Add or import MCP JSON
qoderwake mcp update --waker-id <id> --mcp-id <mid> [options]
qoderwake mcp toggle --waker-id <id> --mcp-id <mid> --enabled true|false
qoderwake mcp delete --waker-id <id> --mcp-id <mid>
qoderwake mcp auth start --waker-id <id> --mcp-id <mid>   # Start OAuth authorization
qoderwake mcp refresh-tools --waker-id <id> --mcp-id <mid># Refresh the tool list

Key add / update options:

Option	Description
`--json <json>` / `--json-file <path>`	Import MCP JSON directly
`--name` / `--description`	Name / description
`--command <cmd>` / `--args <a,b,c>` / `--env <json>`	stdio transport: command / comma-separated args / JSON env vars
`--http-url <url>` / `--transport stdio\|http\|sse`	HTTP/SSE address and transport type
`--headers <json>` / `--header KEY=VALUE`	HTTP/SSE request headers (`--header` is repeatable)
`--oauth-client-metadata-url` / `--oauth-client-id` / `--oauth-client-secret`	OAuth client metadata and credentials
`--oauth-token-auth-method` / `--oauth-scope` / `--oauth-resource-metadata-url`	OAuth token-endpoint auth method / scope / protected-resource metadata

Skill (capability pack)

A Skill is a Waker's capability pack, git-versioned, diff/rollback-able.

qoderwake skill list --waker-id <id>
qoderwake skill add --waker-id <id> [--skill-id|--name|--install-url ...]
qoderwake skill upload <zipPath> --waker-id <id>       # Upload a local zip
qoderwake skill versions --waker-id <id> --skill-id <sid>
qoderwake skill diff --waker-id <id> --skill-id <sid> [--from <v> --to <v>]
qoderwake skill rollback --waker-id <id> --skill-id <sid> --to <versionId>
qoderwake skill toggle --waker-id <id> --skill-id <sid> --enabled true|false
qoderwake skill delete --waker-id <id> --skill-id <sid>
qoderwake skill install --waker-id <id> --skill-id <sid>
qoderwake skill search --keyword <kw>                  # Search the market, returns SKILL_ID+DOWNLOAD_URL
qoderwake skill manage --waker-id <id> --action <a> ... # Managed fine-grained changes

The SKILL_ID + DOWNLOAD_URL returned by skill search can be fed directly to skill add --install-url.
The --action of skill manage can be create / patch / edit / write_file / remove_file, targeting a single Waker or a conversation (choose one of --waker-id or --conversation-id), and supports --dry-run validation.

Permission (permission guard)

Each Waker's permissions consist of four independent sections: tool-guard (tool interception), file-guard (file interception), builtin-tools (built-in tools), and model-security (model security).

qoderwake permission get --waker-id <id> [--json]
qoderwake permission update --waker-id <id> --json <json>|--json-file <path>  # Full replace
qoderwake permission patch <section> --waker-id <id> --json <json>            # Update a single section
qoderwake permission builtin <catalog>                                        # Read-only built-in catalog

patch sections: tool-guard / file-guard / builtin-tools / model-security, all accepting --json or --json-file. builtin read-only catalogs:

qoderwake permission builtin tool-guard-rules [--json]  # Built-in tool interception rules
qoderwake permission builtin tool-catalog [--json]      # Built-in tool catalog

It's recommended to first export the current state with permission get --json, modify it, and then use patch <section> to update only the changed section, to avoid update overwriting everything and losing other sections.

IM channels and pairing (channel)

Channel lifecycle

qoderwake channel settings                    # Global channel settings
qoderwake channel list [--waker-id <id>]      # List channels
qoderwake channel get <channel-id>
qoderwake channel config <channel-id> --json <json>|--json-file <path>
qoderwake channel start <channel-id>          # Start / stop / restart / delete
qoderwake channel stop <channel-id>
qoderwake channel restart <channel-id>
qoderwake channel delete <channel-id>

DingTalk channel registration (QR)

qoderwake channel dingtalk qr-start            # Get the QR code and device code
qoderwake channel dingtalk qr-poll --device-code <code>  # Poll the scan result

pairing — channel-user pairing

The pairing handshake between an external IM identity and a channel, with an approval flow:

qoderwake channel pairing generate-code --channel-id <cid>   # Generate a pairing code
qoderwake channel pairing list --channel-id <cid>            # List pairing records
qoderwake channel pairing pending --channel-id <cid>         # Pending approval
qoderwake channel pairing approve --channel-id <cid> --robot-id <rid> --binding-key <key>
qoderwake channel pairing ignore  --channel-id <cid> --robot-id <rid> --binding-key <key>
qoderwake channel pairing delete <pairing-id>

Extension (local extension runtime)

Read-only view of the local qodercli extension runtime manifest:

qoderwake extension list [--json]

Sessions (session)

A Session is a single run unit of a Waker (id prefix sess_), producing artifacts, file changes, and an event stream.

qoderwake session list --waker-id <id> [--status <s>]
qoderwake session detail --session-id <sid>
qoderwake session artifacts --session-id <sid> [--include-file-changes]
qoderwake session create --waker-id <id> [--title|--message|--cwd|--project-id ...]
qoderwake session send --session-id <sid> --message <msg>          # Send a controller event
qoderwake session rename --session-id <sid> --title <t>
qoderwake session events --session-id <sid> [--after-sequence-num <n>] [--limit <n>]
qoderwake session stream --session-id <sid> [--from-sequence-num <n>]  # SSE stream
qoderwake session trajectory --session-id <sid> [--format markdown|json]

Notes:

session create / send can pass a controller-event array via --events-json <json> or --events-json-file <path>.
session artifacts --include-file-changes can be paginated with --file-changes-limit / --file-changes-cursor.
session trajectory produces a redacted trajectory, written by default to sessions/redacted/<sessionId>.md (--no-write-memory disables it, --force overwrites, --out specifies the output file); use --scope agent|project to write to the corresponding memory scope.

Group conversations (group)

qoderwake group create --title <t> --waker <idOrName> [--sop <sel>] [--param k=v]
qoderwake group list
qoderwake group show <group>          # group = conv_id / unique prefix / unique title
qoderwake group rename <group> --title <t>
qoderwake group add-waker <group> --waker <idOrName>
qoderwake group task rename <conversation> --title <t>   # Rename a task by exact conv id

--waker / --sop / --param are all repeatable; --sop can carry @version and binds in the order passed.

group sop — ordered SOP binding for a group

qoderwake group sop list <group>                       # List bound SOP releases
qoderwake group sop set <group> --sop <sel> [--param k=v]  # Atomically replace the ordered binding
qoderwake group sop clear <group>                      # Clear all bindings

SOP system catalog (sop)

An SOP (Standard Operating Procedure) is a collaboration skill with skill_kind=sop, in a three-layer structure: profile (stable catalog identity) → release (immutable version) → template (editable white-box JSON).

qoderwake sop list                       # List active profiles and immutable releases
qoderwake sop init <file> --skill-id <id> --version <v> --name <n>  # Create an editable template JSON
qoderwake sop validate <file>            # Validate the template JSON
qoderwake sop build <file> [--output <dir>] [--set k=v]  # Render the actually-installed SKILL.md and scripts
qoderwake sop publish --file <file>      # Idempotently publish a template-backed release

sop build's --set k=v is repeatable, used to inject template parameters; the output is exactly the skill directory generated at install time.

Messages / Run / Trace

messages — conversation messages

qoderwake messages list <convId> [--after-seq <n>] [--limit <n>] [--follow]
qoderwake messages send <convId> --text <t> [options]
qoderwake messages claim <convId> [--limit <n>] [--cursor <c>]   # Claim a page of unread Agent messages
qoderwake messages read <convId> --claim <claimId> --message <mid>  # Mark as read
qoderwake messages attachment download <convId> <messageId> <attachmentId> [--out <path>]

Key send options:

Option	Description
`--text <t>`	Message text (unless `--file` is used)
`--mention <idOrName>`	Wake a conversation member (repeatable)
`--private-to <idOrName>`	Visible only to the sender + the specified member (repeatable)
`--reply-to <seqOrId>`	Quote an earlier message
`--if-latest <seq>`	Send only if this is still the latest message you can see
`--intent <intent>`	Intent: `chat` / `ask` / `notify` / `request_action`
`--image <path>` / `--file <path>`	Attachments (both repeatable)
`--model <model>`	Model override for the woken Waker
`--wait` / `--timeout <secs>`	Wait for the wake run triggered by this message to finish (default 120s)

claim/read is a pair of idempotent read mechanisms: claim takes a stable page (returns a claimId), and read then precisely marks 1..N of that claim as read.

runs — conversation run frames

qoderwake runs list <convId>            # List the conversation's runs
qoderwake runs cancel <runId>           # Request cancellation of a run

trace — task chain observability

qoderwake trace list [--source <s>] [--status <st>] [--session-id <sid>] [--since <iso>] [--limit <n>]
qoderwake trace show --trace-id <tid> [--format text|json]

--source: console / cli / api / trigger / im / work / dingtalk / dingtalk-user / dingtalk-ai-assistance / unknown.
--status: arrived / created / queued / dispatching / running / success / failed / cancelled / timeout.
--limit ranges from 1..1000, default 50.

Automations (automation)

Tasks triggered on a schedule (cron) or once (timestamp) (id prefix tr_, legacy command name trigger); a single execution is one rn_ run.

qoderwake automation list --waker-id <id>
qoderwake automation detail --waker-id <id> --automation-id <aid> [--run-id <rid>]
qoderwake automation create schedule [options]
qoderwake automation update --waker-id <id> --automation-id <aid> [options]
qoderwake automation run-now --waker-id <id> --automation-id <aid>
qoderwake automation test-pull --waker-id <id> --automation-id <aid>
qoderwake automation delete --waker-id <id> --automation-id <aid>
qoderwake automation inspect run --run-id <rn_...> [--format table|json|timeline]

Key create schedule options:

Option	Description
`--schedule-type <type>`	`cron` (recurring) or `one-time` (a single ISO 8601 timestamp)
`--cron <expr>`	5-field cron expression (required when `--schedule-type=cron`)
`--cron-preset <preset>`	`daily` / `weekly` / `monthly` / `custom` (default custom)
`--run-at <timestamp>`	ISO 8601 timestamp (required for `one-time`)
`--timezone <tz>`	IANA time zone (default local or Asia/Shanghai)
`--prompt <p>` / `--prompt-file <path>`	Task prompt (choose one)
`--project-id <pid>`	Optional local project binding
`--model <model>`	qodercli model (default auto)
`--enabled <bool>`	Whether enabled (default true)
`--idempotency-key <key>`	Reuse the create-operation key on retry

update can additionally change permissions and pull config: --file-system read|read-write|none, --network true|false, --run-commands true|false, --command-allow-list <a,b,c> (empty string clears), --pull-config-json/--pull-config-file, --permissions-json/--permissions-file; schedule fields can change --schedule-type / --cron / --cron-preset (update additionally supports hourly) / --run-at / --timezone. inspect run is for diagnostics; it can --include-prompt and use --events-limit / --comments-limit / --outbox-limit (1-200) to control the row count of each table.

Memory (memory)

Two scopes: agent (a Waker's long-term memory, default) and project (requires --project-id). All subcommands support --scope agent|project; --agent-id is a deprecated alias of --waker-id.

qoderwake memory show --waker-id <id> [--scope agent|project] [--view index|topics|sessions|all]
qoderwake memory dream --waker-id <id> [--mode preview|apply]     # Manual dream preview/apply
qoderwake memory lifecycle inspect --waker-id <id>               # Daily memory lifecycle summary
qoderwake memory update --waker-id <id> --path <p> --old-text <t> --content <c> [--dry-run]
qoderwake memory remove --waker-id <id> --path <p> --old-text <t> [--dry-run]
qoderwake memory snapshot --waker-id <id> [--include-sessions]   # Manual snapshot
qoderwake memory versions --waker-id <id>                        # List snapshots
qoderwake memory diff --waker-id <id> --from <sid> --to <sid>
qoderwake memory rollback --waker-id <id> --snapshot-id <sid> --path <p> [--apply]
qoderwake memory export --waker-id <id> --out-path <p> [--include-sessions] [--include-versions]
qoderwake memory import --waker-id <id> --package-path <p> [--apply]

Notes:

update / remove are guarded text-range operations that require --old-text to match exactly; they can carry --expected-hash (the guard hash from memory_search) and --reason; --dry-run previews first.
rollback / import only dry-run by default; add --apply to actually write (and a pre-rollback/pre-import snapshot is created first).
The project scope can additionally pass --project-name / --project-root to locate the context and transcript.
show --view accepts index / topics / sessions / all (long_term / daily are compatibility aliases).

Teams (Teams runtime)

Read-only diagnosis of Teams / Mission runtime data:

qoderwake teams diagnose [--mission-id <mid>] [--correlation-id <cid>] [--role-run-id <rid>] [--command-id <cmid>] [--anchor-sequence <n>] [--format text|json]

You can focus a single diagnosis chain by Mission / user-intent correlation chain / RoleRun / ExecutorCommand.

Plugins (plugin)

A Plugin is a trigger/event-source plugin loaded in-process locally.

qoderwake plugin list
qoderwake plugin info <name>
qoderwake plugin install <dir-or-zip> [--enable|--no-enable] [--replace]
qoderwake plugin enable <name> [--version <v>]
qoderwake plugin disable <name>
qoderwake plugin uninstall <name> [--version <v>]
qoderwake plugin reload <name>          # Hot-reload the plugin's events capability
qoderwake plugin events [--json]        # Daemon event catalog + currently subscribed plugins

plugin scheduled-task — declarative scheduled-task registry

qoderwake plugin scheduled-task list [--plugin <name>]
qoderwake plugin scheduled-task register --plugin <name> --task-id <id> --cron <expr> [--payload <json>]
qoderwake plugin scheduled-task unregister --plugin <name> --task-id <id>

Diagnostics and maintenance

qoderwake version                       # Version and platform, e.g. qoderwake 1.0.3 (darwin/arm64)
qoderwake update [--check]              # Upgrade; --check only checks without installing
qoderwake log [traceId] [options]       # Query / follow logs
qoderwake feedback [--email <e>] [--message <m>] [--waker-id <id>]  # Upload local logs as feedback

Key log options:

Option	Description
`[traceId]` / `--trace-id <id>`	Search logs by trace id or session id
`--keyword <kw>`	Search by keyword
`--level <level>`	Minimum level: `debug` / `info` / `warn` / `error`
`--qodercli`	Show qodercli debug logs only
`--clean`	Show only the raw message for structured logs
`--limit <n>`	Limit the number of lines (default 200)
`-f, --follow`	Follow and output new logs

For troubleshooting, first check daemon health with qoderwake status, then locate errors with qoderwake log --level error --limit 100; when official support is needed, package logs with qoderwake feedback.

Environment variables

The following are common, user-facing environment variables you can set directly (from source such as core/paths.ts, core/user-auth.ts, cli/index.ts):

Environment variable	Purpose
`QODERWAKE_HOME`	Override the qoderwake home directory (default `~/.qoderwake`, CN region `~/.qoderwake-cn`)
`QODER_ENV`	Runtime environment: `daily` / `test` / empty (i.e. prod). Daily development needs `export QODER_ENV=daily`
`QODER_PERSONAL_ACCESS_TOKEN`	Personal access token (PAT) for headless environments
`QODER_PERSONAL_ACCESS_TOKEN_FILE`	Read the PAT from a file (takes precedence over the above)
`QODER_USER_INFO`	User info JSON for env authentication
`QODER_MACHINE_ID`	Device machine id (machine binding)
`QODERCLI_PATH`	Specify the qodercli executable path
`QODERWAKE_SETTINGS_PATH`	Override the settings.json path
`QODERWAKE_DEFAULT_WORKSPACE`	Override the default workspace directory
`QODERWAKE_LOG_LEVEL`	Log level (set to `debug` for verbose logging)
`QODERWAKE_ENDPOINT_BASE_URL`	Override the server endpoint base URL (on-prem / VPC)
`QODER_CONFIG_DIR`	Override the CLI config directory

There are also many internal QODER_* / QODERWAKE_* variables (such as QODERWAKE_DAEMON_URL, QODER_AGENT_ID, and various hook timeouts) that the daemon injects into child processes; you do not need to set them manually.

Directory layout (~/.qoderwake)

All of qoderwake's local state lives under the home directory (can be overridden with QODERWAKE_HOME):

Path	Contents
`qoderwake`	The main CLI / daemon binary
`bin/`	Other executables
`qodercli/`	QoderWake-managed qodercli config and skills directory
`config/`	Daemon app config (`config.json`) and `settings.json`
`data/`	Business data (sqlite / file backend: Wakers/projects/sessions/memory, etc.)
`logs/`	Logs (`qoderwake.log`, etc.; this is what `qoderwake log` reads)
`plugins/`	Installed plugins
`extensions/`	Local extension runtimes
`runtimes/` / `runtime-resources/` / `resources/`	Runtimes and built-in resources
`backups/`	Automatic pre-upgrade backups (managed by `qoderwake backup`)
`state/` / `run/`	Runtime state and process/port info
`tools/` / `tmp/` / `.tmp/`	Tools and temporary files
`.auth`	Login credentials
`.installed-version` / `.qodercli-version`	Installed version markers

Common workflows

From zero to ready

export QODER_ENV=daily          # Daily environment (can be omitted for prod)
qoderwake login                 # Browser login
qoderwake start                 # Bring up the daemon
qoderwake status                # Confirm it's online
qoderwake portal                # Open the Console

Create a digital employee and bind a project

qoderwake waker create --name "Backend Assistant" --description "Owns the backend repo"
qoderwake waker list --json                     # Get the wakerId (ag_...)
qoderwake project create --waker-id ag_xxx --name repo --git-url https://...
qoderwake project onboard --waker-id ag_xxx --project-id prj_xxx   # Initial analysis

Configure MCP and Skills

qoderwake mcp add --waker-id ag_xxx --name fs --transport stdio --command npx --args "-y,@modelcontextprotocol/server-filesystem,/tmp"
qoderwake skill search --keyword pdf            # Get SKILL_ID + DOWNLOAD_URL
qoderwake skill add --waker-id ag_xxx --install-url https://...

Create a scheduled automation

qoderwake automation create schedule --waker-id ag_xxx --name "Daily Report" \
  --schedule-type cron --cron "0 9 * * *" --cron-preset daily \
  --timezone Asia/Shanghai --prompt "Generate yesterday's repo-change report"
qoderwake automation run-now --waker-id ag_xxx --automation-id tr_xxx  # Run once immediately
qoderwake automation detail --waker-id ag_xxx --automation-id tr_xxx   # View recent runs

Group conversation + message-driven

qoderwake group create --title "Release Collaboration" --waker ag_a --waker ag_b
qoderwake messages send <convId> --text "Start the release" --mention ag_a --intent request_action --wait
qoderwake messages list <convId> --follow          # Follow in real time

Observability and diagnostics

qoderwake trace list --status failed --limit 20    # Recent failed tasks
qoderwake trace show --trace-id <tid>              # A single chain's details
qoderwake session trajectory --session-id sess_xxx # Redacted trajectory

Troubleshooting quick reference

Symptom	Suggestion
Command reports "daemon unreachable"	First `qoderwake status`; if not running, `qoderwake start`; if the port is taken, `qoderwake start --port auto`
Not logged in / 401	Confirm with `qoderwake whoami`; re-run `qoderwake login`; for headless use `QODER_PERSONAL_ACCESS_TOKEN(_FILE)`
Locate errors	`qoderwake log --level error --limit 100`; by chain `qoderwake log <traceId>`; live with `-f`
Abnormal qodercli behavior	`qoderwake log --qodercli`; if needed, specify the correct binary with `QODERCLI_PATH`
Roll back after an upgrade	`qoderwake stop` → `qoderwake backup list` → `qoderwake backup restore <id>`
Switch the storage backend	`qoderwake storage migrate --from file --to sqlite --switch`
Need official support	`qoderwake feedback --message "..."` to upload local logs

​What it is

​Quick start

​Core concept model

​Global conventions and common options

​Daemon management

​start — start the daemon

​stop / restart

​status — daemon status

​portal — open the local Console

​Authentication and account

​login

​logout / whoami

​Configuration and storage

​config — daemon app config

​settings — user preferences

​storage — storage backend migration

​backup — pre-upgrade backups

​Waker (digital employee)

​Basic CRUD

​waker update — update by field

​waker template — private templates

​Projects (project)

​MCP (external tool integration)

​Skill (capability pack)

​Permission (permission guard)

​IM channels and pairing (channel)

​Channel lifecycle

​DingTalk channel registration (QR)

​pairing — channel-user pairing

​Extension (local extension runtime)

​Sessions (session)

​Group conversations (group)

​group sop — ordered SOP binding for a group

​SOP system catalog (sop)

​Messages / Run / Trace

​messages — conversation messages

​runs — conversation run frames

​trace — task chain observability

​Automations (automation)

​Memory (memory)

​Teams (Teams runtime)

​Plugins (plugin)

​plugin scheduled-task — declarative scheduled-task registry

​Diagnostics and maintenance

​Environment variables

​Directory layout (~/.qoderwake)

​Common workflows

​From zero to ready

​Create a digital employee and bind a project

​Configure MCP and Skills

​Create a scheduled automation

​Group conversation + message-driven

​Observability and diagnostics

​Troubleshooting quick reference

What it is

Quick start

Core concept model

Global conventions and common options

Daemon management

start — start the daemon

stop / restart

status — daemon status

portal — open the local Console

Authentication and account

login

logout / whoami

Configuration and storage

config — daemon app config

settings — user preferences

storage — storage backend migration

backup — pre-upgrade backups

Waker (digital employee)

Basic CRUD

waker update — update by field

waker template — private templates

Projects (project)

MCP (external tool integration)

Skill (capability pack)

Permission (permission guard)

IM channels and pairing (channel)

Channel lifecycle

DingTalk channel registration (QR)

pairing — channel-user pairing

Extension (local extension runtime)

Sessions (session)

Group conversations (group)

group sop — ordered SOP binding for a group

SOP system catalog (sop)

Messages / Run / Trace

messages — conversation messages

runs — conversation run frames

trace — task chain observability

Automations (automation)

Memory (memory)

Teams (Teams runtime)

Plugins (plugin)

plugin scheduled-task — declarative scheduled-task registry

Diagnostics and maintenance

Environment variables

Directory layout (~/.qoderwake)

Common workflows

From zero to ready

Create a digital employee and bind a project

Configure MCP and Skills

Create a scheduled automation

Group conversation + message-driven

Observability and diagnostics

Troubleshooting quick reference