Sign-in and Verification
commander-key accepts provider (anthropic or openai) and a non-empty
credential, stores it through the encrypted company-secret path, and records the
mutation. Login challenges are company-scoped; a concurrent challenge returns
409, and a provider start failure returns 502.
Chat, Conversation, and Runs
/chat is POST-based SSE streaming (text/event-stream); the browser client uses fetch, not EventSource, so request bodies and abort signals work. Conversation routes persist user, assistant, and tool messages and support session list management. Run routes expose execution metadata and tool/cost traces.
A chat request includes:
message is required and limited to 10,000 characters. pageContext is limited
to 5,000 characters, clientSubmissionId to 200 characters, and attachments to
five company-owned assets.
clientSubmissionId makes retries replay-safe within the conversation context.
An accepted or in-progress replay does not launch a second CLI turn or persist a
duplicate user message.
The stream may emit thinking, content, reasoning, tool_call,
tool_result, action_confirm, options_prompt, error, and done events.
Clients should treat event payloads as typed stream events and wait for done
or error rather than parsing display text.
Composer uploads use the company asset endpoint. Plain text, Markdown, and JSON
assets are runtime-readable up to 32 KB; images and other formats are stored and
disclosed but not delivered to the current model runtime. Delivery is
best-effort and never bypasses company ownership checks. See
Commander attachment runtime.
Settings, Capabilities, and Reminders
Autonomy: two independent dials
internal_agent_config carries two separate autonomy columns. They are set independently and neither is derived from the other — writing one never moves the other. Both accept 0 (Manual), 1 (Assist), or 2 (Drive); 3 is rejected. Both default to 1. (D18 split, 2026-07-24 — see Decision #109 addendum §10-14.)
Two things about these names are deliberate and worth knowing before you use them:
crewAutonomyLevelalso governs ORG agents, not just crew. The name follows the D18 decision, but the dial answers “how far may an agent take its own task”, which is the same question for a crew agent and an org-agent heartbeat run. If you are setting autonomy for any agent execution, this is the field. The Settings UI labels it “Agent autonomy (crew + org agents)” for the same reason.autonomyLevelis currently inert. No Commander code path reads it. Commander’s gating is the runtime-approval policy (runtimeApprovalsEnabled/runtimeAllowAlwaysEnabledabove), which is unconditional for Commander. The column is retained as Commander’s declared dial and round-trips through portability bundles, but changing it changes no behaviour today.
PATCH sending autonomyLevel to control agents must be changed to crewAutonomyLevel. The old field still validates and still writes — it simply no longer affects agent execution, so the failure is silent.
discussions.autonomyLevel (see docs/api/discussions.md) remains a third, finer-grained per-thread override that outranks crewAutonomyLevel for that thread. Resolution is thread.autonomyLevel ?? company.crewAutonomyLevel.
Cockpit
/cockpitreturns bounded card slices, per-slice status metadata, Active Work split intomineandmanaged, and a separateawaitingReviewqueue. A failed independent slice setsmeta.partialinstead of presenting a false all-clear state./cockpit/countssupplies lightweight collapsed-rail counts without loading every Cockpit card./cockpit/tasksprovides stable cursor pagination for the three accountable-work queues. Cursors are opaque and tied to the selected bucket’s ranking order.
in_review tasks. mine wins when a task also matches the user’s responsibility hierarchy. managed follows the bounded mixed human/agent reporting graph, while awaiting_review includes explicit reviewer assignments and review work in that responsibility scope.