@captain-app/openclaw 2026.2.4

package/docs/environment.md

@@ -0,0 +1,81 @@
+---
+summary: "Where OpenClaw loads environment variables and the precedence order"
+read_when:
+  - You need to know which env vars are loaded, and in what order
+  - You are debugging missing API keys in the Gateway
+  - You are documenting provider auth or deployment environments
+title: "Environment Variables"
+---
+
+# Environment variables
+
+OpenClaw pulls environment variables from multiple sources. The rule is **never override existing values**.
+
+## Precedence (highest → lowest)
+
+1. **Process environment** (what the Gateway process already has from the parent shell/daemon).
+2. **`.env` in the current working directory** (dotenv default; does not override).
+3. **Global `.env`** at `~/.openclaw/.env` (aka `$OPENCLAW_STATE_DIR/.env`; does not override).
+4. **Config `env` block** in `~/.openclaw/openclaw.json` (applied only if missing).
+5. **Optional login-shell import** (`env.shellEnv.enabled` or `OPENCLAW_LOAD_SHELL_ENV=1`), applied only for missing expected keys.
+
+If the config file is missing entirely, step 4 is skipped; shell import still runs if enabled.
+
+## Config `env` block
+
+Two equivalent ways to set inline env vars (both are non-overriding):
+
+```json5
+{
+  env: {
+    OPENROUTER_API_KEY: "sk-or-...",
+    vars: {
+      GROQ_API_KEY: "gsk-...",
+    },
+  },
+}
+```
+
+## Shell env import
+
+`env.shellEnv` runs your login shell and imports only **missing** expected keys:
+
+```json5
+{
+  env: {
+    shellEnv: {
+      enabled: true,
+      timeoutMs: 15000,
+    },
+  },
+}
+```
+
+Env var equivalents:
+
+- `OPENCLAW_LOAD_SHELL_ENV=1`
+- `OPENCLAW_SHELL_ENV_TIMEOUT_MS=15000`
+
+## Env var substitution in config
+
+You can reference env vars directly in config string values using `${VAR_NAME}` syntax:
+
+```json5
+{
+  models: {
+    providers: {
+      "vercel-gateway": {
+        apiKey: "${VERCEL_GATEWAY_API_KEY}",
+      },
+    },
+  },
+}
+```
+
+See [Configuration: Env var substitution](/gateway/configuration#env-var-substitution-in-config) for full details.
+
+## Related
+
+- [Gateway configuration](/gateway/configuration)
+- [FAQ: env vars and .env loading](/help/faq#env-vars-and-env-loading)
+- [Models overview](/concepts/models)

package/docs/experiments/onboarding-config-protocol.md

@@ -0,0 +1,40 @@
+---
+summary: "RPC protocol notes for onboarding wizard and config schema"
+read_when: "Changing onboarding wizard steps or config schema endpoints"
+title: "Onboarding and Config Protocol"
+---
+
+# Onboarding + Config Protocol
+
+Purpose: shared onboarding + config surfaces across CLI, macOS app, and Web UI.
+
+## Components
+
+- Wizard engine (shared session + prompts + onboarding state).
+- CLI onboarding uses the same wizard flow as the UI clients.
+- Gateway RPC exposes wizard + config schema endpoints.
+- macOS onboarding uses the wizard step model.
+- Web UI renders config forms from JSON Schema + UI hints.
+
+## Gateway RPC
+
+- `wizard.start` params: `{ mode?: "local"|"remote", workspace?: string }`
+- `wizard.next` params: `{ sessionId, answer?: { stepId, value? } }`
+- `wizard.cancel` params: `{ sessionId }`
+- `wizard.status` params: `{ sessionId }`
+- `config.schema` params: `{}`
+
+Responses (shape)
+
+- Wizard: `{ sessionId, done, step?, status?, error? }`
+- Config schema: `{ schema, uiHints, version, generatedAt }`
+
+## UI Hints
+
+- `uiHints` keyed by path; optional metadata (label/help/group/order/advanced/sensitive/placeholder).
+- Sensitive fields render as password inputs; no redaction layer.
+- Unsupported schema nodes fall back to the raw JSON editor.
+
+## Notes
+
+- This doc is the single place to track protocol refactors for onboarding/config.

package/docs/experiments/plans/cron-add-hardening.md

@@ -0,0 +1,63 @@
+---
+summary: "Harden cron.add input handling, align schemas, and improve cron UI/agent tooling"
+owner: "openclaw"
+status: "complete"
+last_updated: "2026-01-05"
+title: "Cron Add Hardening"
+---
+
+# Cron Add Hardening & Schema Alignment
+
+## Context
+
+Recent gateway logs show repeated `cron.add` failures with invalid parameters (missing `sessionTarget`, `wakeMode`, `payload`, and malformed `schedule`). This indicates that at least one client (likely the agent tool call path) is sending wrapped or partially specified job payloads. Separately, there is drift between cron provider enums in TypeScript, gateway schema, CLI flags, and UI form types, plus a UI mismatch for `cron.status` (expects `jobCount` while gateway returns `jobs`).
+
+## Goals
+
+- Stop `cron.add` INVALID_REQUEST spam by normalizing common wrapper payloads and inferring missing `kind` fields.
+- Align cron provider lists across gateway schema, cron types, CLI docs, and UI forms.
+- Make agent cron tool schema explicit so the LLM produces correct job payloads.
+- Fix the Control UI cron status job count display.
+- Add tests to cover normalization and tool behavior.
+
+## Non-goals
+
+- Change cron scheduling semantics or job execution behavior.
+- Add new schedule kinds or cron expression parsing.
+- Overhaul the UI/UX for cron beyond the necessary field fixes.
+
+## Findings (current gaps)
+
+- `CronPayloadSchema` in gateway excludes `signal` + `imessage`, while TS types include them.
+- Control UI CronStatus expects `jobCount`, but gateway returns `jobs`.
+- Agent cron tool schema allows arbitrary `job` objects, enabling malformed inputs.
+- Gateway strictly validates `cron.add` with no normalization, so wrapped payloads fail.
+
+## What changed
+
+- `cron.add` and `cron.update` now normalize common wrapper shapes and infer missing `kind` fields.
+- Agent cron tool schema matches the gateway schema, which reduces invalid payloads.
+- Provider enums are aligned across gateway, CLI, UI, and macOS picker.
+- Control UI uses the gateway’s `jobs` count field for status.
+
+## Current behavior
+
+- **Normalization:** wrapped `data`/`job` payloads are unwrapped; `schedule.kind` and `payload.kind` are inferred when safe.
+- **Defaults:** safe defaults are applied for `wakeMode` and `sessionTarget` when missing.
+- **Providers:** Discord/Slack/Signal/iMessage are now consistently surfaced across CLI/UI.
+
+See [Cron jobs](/automation/cron-jobs) for the normalized shape and examples.
+
+## Verification
+
+- Watch gateway logs for reduced `cron.add` INVALID_REQUEST errors.
+- Confirm Control UI cron status shows job count after refresh.
+
+## Optional Follow-ups
+
+- Manual Control UI smoke: add a cron job per provider + verify status job count.
+
+## Open Questions
+
+- Should `cron.add` accept explicit `state` from clients (currently disallowed by schema)?
+- Should we allow `webchat` as an explicit delivery provider (currently filtered in delivery resolution)?

package/docs/experiments/plans/group-policy-hardening.md

@@ -0,0 +1,40 @@
+---
+summary: "Telegram allowlist hardening: prefix + whitespace normalization"
+read_when:
+  - Reviewing historical Telegram allowlist changes
+title: "Telegram Allowlist Hardening"
+---
+
+# Telegram Allowlist Hardening
+
+**Date**: 2026-01-05  
+**Status**: Complete  
+**PR**: #216
+
+## Summary
+
+Telegram allowlists now accept `telegram:` and `tg:` prefixes case-insensitively, and tolerate
+accidental whitespace. This aligns inbound allowlist checks with outbound send normalization.
+
+## What changed
+
+- Prefixes `telegram:` and `tg:` are treated the same (case-insensitive).
+- Allowlist entries are trimmed; empty entries are ignored.
+
+## Examples
+
+All of these are accepted for the same ID:
+
+- `telegram:123456`
+- `TG:123456`
+- `tg:123456`
+
+## Why it matters
+
+Copy/paste from logs or chat IDs often includes prefixes and whitespace. Normalizing avoids
+false negatives when deciding whether to respond in DMs or groups.
+
+## Related docs
+
+- [Group Chats](/concepts/groups)
+- [Telegram Provider](/channels/telegram)

package/docs/experiments/plans/openresponses-gateway.md

@@ -0,0 +1,123 @@
+---
+summary: "Plan: Add OpenResponses /v1/responses endpoint and deprecate chat completions cleanly"
+owner: "openclaw"
+status: "draft"
+last_updated: "2026-01-19"
+title: "OpenResponses Gateway Plan"
+---
+
+# OpenResponses Gateway Integration Plan
+
+## Context
+
+OpenClaw Gateway currently exposes a minimal OpenAI-compatible Chat Completions endpoint at
+`/v1/chat/completions` (see [OpenAI Chat Completions](/gateway/openai-http-api)).
+
+Open Responses is an open inference standard based on the OpenAI Responses API. It is designed
+for agentic workflows and uses item-based inputs plus semantic streaming events. The OpenResponses
+spec defines `/v1/responses`, not `/v1/chat/completions`.
+
+## Goals
+
+- Add a `/v1/responses` endpoint that adheres to OpenResponses semantics.
+- Keep Chat Completions as a compatibility layer that is easy to disable and eventually remove.
+- Standardize validation and parsing with isolated, reusable schemas.
+
+## Non-goals
+
+- Full OpenResponses feature parity in the first pass (images, files, hosted tools).
+- Replacing internal agent execution logic or tool orchestration.
+- Changing the existing `/v1/chat/completions` behavior during the first phase.
+
+## Research Summary
+
+Sources: OpenResponses OpenAPI, OpenResponses specification site, and the Hugging Face blog post.
+
+Key points extracted:
+
+- `POST /v1/responses` accepts `CreateResponseBody` fields like `model`, `input` (string or
+  `ItemParam[]`), `instructions`, `tools`, `tool_choice`, `stream`, `max_output_tokens`, and
+  `max_tool_calls`.
+- `ItemParam` is a discriminated union of:
+  - `message` items with roles `system`, `developer`, `user`, `assistant`
+  - `function_call` and `function_call_output`
+  - `reasoning`
+  - `item_reference`
+- Successful responses return a `ResponseResource` with `object: "response"`, `status`, and
+  `output` items.
+- Streaming uses semantic events such as:
+  - `response.created`, `response.in_progress`, `response.completed`, `response.failed`
+  - `response.output_item.added`, `response.output_item.done`
+  - `response.content_part.added`, `response.content_part.done`
+  - `response.output_text.delta`, `response.output_text.done`
+- The spec requires:
+  - `Content-Type: text/event-stream`
+  - `event:` must match the JSON `type` field
+  - terminal event must be literal `[DONE]`
+- Reasoning items may expose `content`, `encrypted_content`, and `summary`.
+- HF examples include `OpenResponses-Version: latest` in requests (optional header).
+
+## Proposed Architecture
+
+- Add `src/gateway/open-responses.schema.ts` containing Zod schemas only (no gateway imports).
+- Add `src/gateway/openresponses-http.ts` (or `open-responses-http.ts`) for `/v1/responses`.
+- Keep `src/gateway/openai-http.ts` intact as a legacy compatibility adapter.
+- Add config `gateway.http.endpoints.responses.enabled` (default `false`).
+- Keep `gateway.http.endpoints.chatCompletions.enabled` independent; allow both endpoints to be
+  toggled separately.
+- Emit a startup warning when Chat Completions is enabled to signal legacy status.
+
+## Deprecation Path for Chat Completions
+
+- Maintain strict module boundaries: no shared schema types between responses and chat completions.
+- Make Chat Completions opt-in by config so it can be disabled without code changes.
+- Update docs to label Chat Completions as legacy once `/v1/responses` is stable.
+- Optional future step: map Chat Completions requests to the Responses handler for a simpler
+  removal path.
+
+## Phase 1 Support Subset
+
+- Accept `input` as string or `ItemParam[]` with message roles and `function_call_output`.
+- Extract system and developer messages into `extraSystemPrompt`.
+- Use the most recent `user` or `function_call_output` as the current message for agent runs.
+- Reject unsupported content parts (image/file) with `invalid_request_error`.
+- Return a single assistant message with `output_text` content.
+- Return `usage` with zeroed values until token accounting is wired.
+
+## Validation Strategy (No SDK)
+
+- Implement Zod schemas for the supported subset of:
+  - `CreateResponseBody`
+  - `ItemParam` + message content part unions
+  - `ResponseResource`
+  - Streaming event shapes used by the gateway
+- Keep schemas in a single, isolated module to avoid drift and allow future codegen.
+
+## Streaming Implementation (Phase 1)
+
+- SSE lines with both `event:` and `data:`.
+- Required sequence (minimum viable):
+  - `response.created`
+  - `response.output_item.added`
+  - `response.content_part.added`
+  - `response.output_text.delta` (repeat as needed)
+  - `response.output_text.done`
+  - `response.content_part.done`
+  - `response.completed`
+  - `[DONE]`
+
+## Tests and Verification Plan
+
+- Add e2e coverage for `/v1/responses`:
+  - Auth required
+  - Non-stream response shape
+  - Stream event ordering and `[DONE]`
+  - Session routing with headers and `user`
+- Keep `src/gateway/openai-http.e2e.test.ts` unchanged.
+- Manual: curl to `/v1/responses` with `stream: true` and verify event ordering and terminal
+  `[DONE]`.
+
+## Doc Updates (Follow-up)
+
+- Add a new docs page for `/v1/responses` usage and examples.
+- Update `/gateway/openai-http-api` with a legacy note and pointer to `/v1/responses`.

package/docs/experiments/proposals/model-config.md

@@ -0,0 +1,36 @@
+---
+summary: "Exploration: model config, auth profiles, and fallback behavior"
+read_when:
+  - Exploring future model selection + auth profile ideas
+title: "Model Config Exploration"
+---
+
+# Model Config (Exploration)
+
+This document captures **ideas** for future model configuration. It is not a
+shipping spec. For current behavior, see:
+
+- [Models](/concepts/models)
+- [Model failover](/concepts/model-failover)
+- [OAuth + profiles](/concepts/oauth)
+
+## Motivation
+
+Operators want:
+
+- Multiple auth profiles per provider (personal vs work).
+- Simple `/model` selection with predictable fallbacks.
+- Clear separation between text models and image-capable models.
+
+## Possible direction (high level)
+
+- Keep model selection simple: `provider/model` with optional aliases.
+- Let providers have multiple auth profiles, with an explicit order.
+- Use a global fallback list so all sessions fail over consistently.
+- Only override image routing when explicitly configured.
+
+## Open questions
+
+- Should profile rotation be per-provider or per-model?
+- How should the UI surface profile selection for a session?
+- What is the safest migration path from legacy config keys?

package/docs/experiments/research/memory.md

@@ -0,0 +1,228 @@
+---
+summary: "Research notes: offline memory system for Clawd workspaces (Markdown source-of-truth + derived index)"
+read_when:
+  - Designing workspace memory (~/.openclaw/workspace) beyond daily Markdown logs
+  - Deciding: standalone CLI vs deep OpenClaw integration
+  - Adding offline recall + reflection (retain/recall/reflect)
+title: "Workspace Memory Research"
+---
+
+# Workspace Memory v2 (offline): research notes
+
+Target: Clawd-style workspace (`agents.defaults.workspace`, default `~/.openclaw/workspace`) where “memory” is stored as one Markdown file per day (`memory/YYYY-MM-DD.md`) plus a small set of stable files (e.g. `memory.md`, `SOUL.md`).
+
+This doc proposes an **offline-first** memory architecture that keeps Markdown as the canonical, reviewable source of truth, but adds **structured recall** (search, entity summaries, confidence updates) via a derived index.
+
+## Why change?
+
+The current setup (one file per day) is excellent for:
+
+- “append-only” journaling
+- human editing
+- git-backed durability + auditability
+- low-friction capture (“just write it down”)
+
+It’s weak for:
+
+- high-recall retrieval (“what did we decide about X?”, “last time we tried Y?”)
+- entity-centric answers (“tell me about Alice / The Castle / warelay”) without rereading many files
+- opinion/preference stability (and evidence when it changes)
+- time constraints (“what was true during Nov 2025?”) and conflict resolution
+
+## Design goals
+
+- **Offline**: works without network; can run on laptop/Castle; no cloud dependency.
+- **Explainable**: retrieved items should be attributable (file + location) and separable from inference.
+- **Low ceremony**: daily logging stays Markdown, no heavy schema work.
+- **Incremental**: v1 is useful with FTS only; semantic/vector and graphs are optional upgrades.
+- **Agent-friendly**: makes “recall within token budgets” easy (return small bundles of facts).
+
+## North star model (Hindsight × Letta)
+
+Two pieces to blend:
+
+1. **Letta/MemGPT-style control loop**
+
+- keep a small “core” always in context (persona + key user facts)
+- everything else is out-of-context and retrieved via tools
+- memory writes are explicit tool calls (append/replace/insert), persisted, then re-injected next turn
+
+2. **Hindsight-style memory substrate**
+
+- separate what’s observed vs what’s believed vs what’s summarized
+- support retain/recall/reflect
+- confidence-bearing opinions that can evolve with evidence
+- entity-aware retrieval + temporal queries (even without full knowledge graphs)
+
+## Proposed architecture (Markdown source-of-truth + derived index)
+
+### Canonical store (git-friendly)
+
+Keep `~/.openclaw/workspace` as canonical human-readable memory.
+
+Suggested workspace layout:
+
+```
+~/.openclaw/workspace/
+  memory.md                    # small: durable facts + preferences (core-ish)
+  memory/
+    YYYY-MM-DD.md              # daily log (append; narrative)
+  bank/                        # “typed” memory pages (stable, reviewable)
+    world.md                   # objective facts about the world
+    experience.md              # what the agent did (first-person)
+    opinions.md                # subjective prefs/judgments + confidence + evidence pointers
+    entities/
+      Peter.md
+      The-Castle.md
+      warelay.md
+      ...
+```
+
+Notes:
+
+- **Daily log stays daily log**. No need to turn it into JSON.
+- The `bank/` files are **curated**, produced by reflection jobs, and can still be edited by hand.
+- `memory.md` remains “small + core-ish”: the things you want Clawd to see every session.
+
+### Derived store (machine recall)
+
+Add a derived index under the workspace (not necessarily git tracked):
+
+```
+~/.openclaw/workspace/.memory/index.sqlite
+```
+
+Back it with:
+
+- SQLite schema for facts + entity links + opinion metadata
+- SQLite **FTS5** for lexical recall (fast, tiny, offline)
+- optional embeddings table for semantic recall (still offline)
+
+The index is always **rebuildable from Markdown**.
+
+## Retain / Recall / Reflect (operational loop)
+
+### Retain: normalize daily logs into “facts”
+
+Hindsight’s key insight that matters here: store **narrative, self-contained facts**, not tiny snippets.
+
+Practical rule for `memory/YYYY-MM-DD.md`:
+
+- at end of day (or during), add a `## Retain` section with 2–5 bullets that are:
+  - narrative (cross-turn context preserved)
+  - self-contained (standalone makes sense later)
+  - tagged with type + entity mentions
+
+Example:
+
+```
+## Retain
+- W @Peter: Currently in Marrakech (Nov 27–Dec 1, 2025) for Andy’s birthday.
+- B @warelay: I fixed the Baileys WS crash by wrapping connection.update handlers in try/catch (see memory/2025-11-27.md).
+- O(c=0.95) @Peter: Prefers concise replies (<1500 chars) on WhatsApp; long content goes into files.
+```
+
+Minimal parsing:
+
+- Type prefix: `W` (world), `B` (experience/biographical), `O` (opinion), `S` (observation/summary; usually generated)
+- Entities: `@Peter`, `@warelay`, etc (slugs map to `bank/entities/*.md`)
+- Opinion confidence: `O(c=0.0..1.0)` optional
+
+If you don’t want authors to think about it: the reflect job can infer these bullets from the rest of the log, but having an explicit `## Retain` section is the easiest “quality lever”.
+
+### Recall: queries over the derived index
+
+Recall should support:
+
+- **lexical**: “find exact terms / names / commands” (FTS5)
+- **entity**: “tell me about X” (entity pages + entity-linked facts)
+- **temporal**: “what happened around Nov 27” / “since last week”
+- **opinion**: “what does Peter prefer?” (with confidence + evidence)
+
+Return format should be agent-friendly and cite sources:
+
+- `kind` (`world|experience|opinion|observation`)
+- `timestamp` (source day, or extracted time range if present)
+- `entities` (`["Peter","warelay"]`)
+- `content` (the narrative fact)
+- `source` (`memory/2025-11-27.md#L12` etc)
+
+### Reflect: produce stable pages + update beliefs
+
+Reflection is a scheduled job (daily or heartbeat `ultrathink`) that:
+
+- updates `bank/entities/*.md` from recent facts (entity summaries)
+- updates `bank/opinions.md` confidence based on reinforcement/contradiction
+- optionally proposes edits to `memory.md` (“core-ish” durable facts)
+
+Opinion evolution (simple, explainable):
+
+- each opinion has:
+  - statement
+  - confidence `c ∈ [0,1]`
+  - last_updated
+  - evidence links (supporting + contradicting fact IDs)
+- when new facts arrive:
+  - find candidate opinions by entity overlap + similarity (FTS first, embeddings later)
+  - update confidence by small deltas; big jumps require strong contradiction + repeated evidence
+
+## CLI integration: standalone vs deep integration
+
+Recommendation: **deep integration in OpenClaw**, but keep a separable core library.
+
+### Why integrate into OpenClaw?
+
+- OpenClaw already knows:
+  - the workspace path (`agents.defaults.workspace`)
+  - the session model + heartbeats
+  - logging + troubleshooting patterns
+- You want the agent itself to call the tools:
+  - `openclaw memory recall "…" --k 25 --since 30d`
+  - `openclaw memory reflect --since 7d`
+
+### Why still split a library?
+
+- keep memory logic testable without gateway/runtime
+- reuse from other contexts (local scripts, future desktop app, etc.)
+
+Shape:
+The memory tooling is intended to be a small CLI + library layer, but this is exploratory only.
+
+## “S-Collide” / SuCo: when to use it (research)
+
+If “S-Collide” refers to **SuCo (Subspace Collision)**: it’s an ANN retrieval approach that targets strong recall/latency tradeoffs by using learned/structured collisions in subspaces (paper: arXiv 2411.14754, 2024).
+
+Pragmatic take for `~/.openclaw/workspace`:
+
+- **don’t start** with SuCo.
+- start with SQLite FTS + (optional) simple embeddings; you’ll get most UX wins immediately.
+- consider SuCo/HNSW/ScaNN-class solutions only once:
+  - corpus is big (tens/hundreds of thousands of chunks)
+  - brute-force embedding search becomes too slow
+  - recall quality is meaningfully bottlenecked by lexical search
+
+Offline-friendly alternatives (in increasing complexity):
+
+- SQLite FTS5 + metadata filters (zero ML)
+- Embeddings + brute force (works surprisingly far if chunk count is low)
+- HNSW index (common, robust; needs a library binding)
+- SuCo (research-grade; attractive if there’s a solid implementation you can embed)
+
+Open question:
+
+- what’s the **best** offline embedding model for “personal assistant memory” on your machines (laptop + desktop)?
+  - if you already have Ollama: embed with a local model; otherwise ship a small embedding model in the toolchain.
+
+## Smallest useful pilot
+
+If you want a minimal, still-useful version:
+
+- Add `bank/` entity pages and a `## Retain` section in daily logs.
+- Use SQLite FTS for recall with citations (path + line numbers).
+- Add embeddings only if recall quality or scale demands it.
+
+## References
+
+- Letta / MemGPT concepts: “core memory blocks” + “archival memory” + tool-driven self-editing memory.
+- Hindsight Technical Report: “retain / recall / reflect”, four-network memory, narrative fact extraction, opinion confidence evolution.
+- SuCo: arXiv 2411.14754 (2024): “Subspace Collision” approximate nearest neighbor retrieval.