feat(audit): post-write hook registry for in-process exporters

registerAuditHook({ name, onEvent, init?, maintain?, shutdown? }) — the
in-process extension seam for future exporters, following the tree's
observer idiom (registerApprovalResolvedHandler et al). Hooks observe
the LOG, not the event stream: onEvent(event, line) fires only after
the event was durably appended to the local day-file, so exported ⊆
written holds by construction — an external system can never know an
event the source of truth doesn't, and a hook that misses events
catches up by reading the day-files (the at-least-once story).

Failures are isolated everywhere: a throwing hook is logged with its
name and never affects the log, other hooks, or the audited action; a
failing append means hooks are not called at all. Lifecycle: init at
boot (throw = refuse to start, same posture as the writability assert),
maintain from the 60s host-sweep (now one maintainAudit() entry point
covering retention prune + hooks), shutdown via the host's graceful-
shutdown registry.

No forwarder, credentials, or transport ships in core — an exporter is
an in-tree or skill-installed module that registers itself; external
services keep the zero-code paths (tail data/audit/*.ndjson, or poll
ncl audit list --format ndjson).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

.claude/skills/add-audit/REMOVE.md

@@ -1,52 +0,0 @@
-# Remove /add-audit
-
-Reverses every change the skill made. Safe to re-run even if some pieces are
-already gone. Run from the NanoClaw project root.
-
-## 1. Delete the copied files
-
-```bash
-rm -rf src/audit
-rm -f src/cli/dispatch.audit.ts src/cli/dispatch.audit.test.ts
-rm -f src/cli/resources/audit.ts
-rm -f src/audit-wiring.test.ts
-```
-
-## 2. Revert the dispatch composition
-
-In `src/cli/dispatch.ts`, delete (not comment out) the three edits the skill
-made:
-
-1. The import line: `import { withAudit } from './dispatch.audit.js';`
-2. The composition block (comment + `export const dispatch = withAudit(dispatchInner);`)
-3. Rename the dispatcher back — change `async function dispatchInner(` to
-   `export async function dispatch(`
-
-## 3. Unregister the resource
-
-Delete the `import './audit.js';` line from `src/cli/resources/index.ts`.
-
-## 4. Remove the settings
-
-Delete the `AUDIT_ENABLED` and `AUDIT_RETENTION_DAYS` lines from `.env`.
-
-## 5. Rebuild and restart
-
-```bash
-pnpm run build
-source setup/lib/install-slug.sh
-launchctl kickstart -k gui/$(id -u)/$(launchd_label)   # macOS
-# systemctl --user restart $(systemd_unit)             # Linux
-```
-
-## Day-files
-
-`data/audit/*.ndjson` are the operator's records and are deliberately left in
-place. To purge them too:
-
-```bash
-rm -rf data/audit
-```
-
-No dependency was added, nothing under `container/` was touched, and no DB
-schema changed — there is nothing else to undo.

.claude/skills/add-audit/SKILL.md

@@ -1,211 +0,0 @@
----
-name: add-audit
-description: Add an opt-in local audit log for the ncl command surface — every dispatch outcome on both transports (host socket and container), including scope denials, approval holds, and approved replays, written as SIEM-shaped append-only NDJSON day-files under data/audit/. Read back with `ncl audit list`; plug exporters in via registerAuditHook. Off until AUDIT_ENABLED=true.
----
-
-# /add-audit — Local Audit Log (ncl surface)
-
-Records one canonical audit event for every command that reaches the `ncl`
-dispatcher — human over the host socket or agent over the container transport
-— including denials. Both transports converge on the exported `dispatch`, so
-one composition covers the whole surface: there is no second door.
-
-```
-ncl (host socket) ──┐
-                    ├─→ dispatch = withAudit(dispatchInner) ─→ one NDJSON line
-container cli_request ┘        │                               data/audit/<UTC-day>.ndjson
-approved replay (grant) ───────┘
-```
-
-What one event carries: `actor` (`host:<os-user>` or the agent group),
-`origin` (transport, session, channel), dotted `action` from the guard
-catalog (e.g. `groups.config.add-mcp-server`), touched/attempted `resources`,
-`outcome` (`success · failure · denied · pending`), `correlation_id` (the
-approval id on gated chains — the pending event and the approved replay share
-it, so `--correlation <id>` returns the whole chain), and redacted `details`.
-
-Scope of this increment: the ncl dispatch surface only. Approval-lifecycle
-events (request/decision as their own events), OneCLI credential holds, and
-channel/sender events are later increments — they attach to `src/audit/` as
-pure adds (new `*.audit.ts` adapters and observer subscriptions).
-
-## Steps
-
-### 0. Pre-flight (idempotency)
-
-The apply is safe to re-run; every step below is guarded. Skip to
-**Enable** if all of these already hold:
-
-- `src/audit/` exists
-- `src/cli/resources/index.ts` contains `import './audit.js';`
-- `src/cli/dispatch.ts` contains `export const dispatch = withAudit(dispatchInner);`
-
-Before editing, verify the reach-in targets still exist: `src/cli/dispatch.ts`
-must contain `export async function dispatch(` (or the already-applied
-composition), and `src/cli/resources/index.ts` must be the resource barrel (a
-list of `import './<resource>.js';` lines). If either has moved, stop and
-adapt rather than guessing.
-
-### 1. Copy the payload
-
-From the NanoClaw project root:
-
-```bash
-cp -R "${CLAUDE_SKILL_DIR}/add/src/." src/
-```
-
-What lands (mirrors of the destination paths):
-
-- `src/audit/` — the domain-free leaf: event schema (`types.ts`), env config
-  (`config.ts`), redactor, NDJSON day-file store, emit seam, post-write hooks,
-  reader, boot/maintenance wiring, vocabulary — plus its tests.
-- `src/cli/dispatch.audit.ts` — the CLI adapter: `withAudit` middleware and
-  the actor/origin/resource mapping (+ `dispatch.audit.test.ts`).
-- `src/cli/resources/audit.ts` — the read-only `ncl audit` resource.
-- `src/audit-wiring.test.ts` — goes red if either core edit below is deleted
-  or drifts.
-
-### 2. Register the resource
-
-Append to `src/cli/resources/index.ts` (skip if the line is already present):
-
-```typescript
-import './audit.js';
-```
-
-### 3. Compose the dispatch middleware
-
-This is the skill's one functional reach-in, in `src/cli/dispatch.ts`. Three
-small edits:
-
-1. Add the import (next to the other `./` imports):
-
-   ```typescript
-   import { withAudit } from './dispatch.audit.js';
-   ```
-
-2. Rename the dispatcher declaration — change
-
-   ```typescript
-   export async function dispatch(
-   ```
-
-   to
-
-   ```typescript
-   async function dispatchInner(
-   ```
-
-3. Directly after that function's closing brace (before the
-   `registerApprovalHandler('cli_command', …)` block), add:
-
-   ```typescript
-   // Audit middleware (installed by /add-audit): the exported dispatch is the
-   // wrapped function, so both transports and the approved replay below all
-   // pass the one composition.
-   export const dispatch = withAudit(dispatchInner);
-   ```
-
-The composition must live at the definition site (not at the import sites):
-the approved-replay handler in the same file calls `dispatch(...)` too, and
-only the wrapped export covers it. `src/audit-wiring.test.ts` asserts exactly
-this shape via the TypeScript AST.
-
-Loading `dispatch.audit.ts` also boots the audit log: on an enabled box it
-asserts `data/audit/` is writable (refusing to start beats a silent audit
-gap), runs the boot retention prune, and arms an unref'd maintenance timer.
-Nothing else in core changes — no `index.ts` or `host-sweep.ts` edits.
-
-### 4. Enable
-
-Add the two settings to `.env` (idempotent — overwrite or append):
-
-```bash
-grep -q '^AUDIT_ENABLED=' .env && sed -i.bak 's/^AUDIT_ENABLED=.*/AUDIT_ENABLED=true/' .env && rm -f .env.bak || echo 'AUDIT_ENABLED=true' >> .env
-grep -q '^AUDIT_RETENTION_DAYS=' .env || echo 'AUDIT_RETENTION_DAYS=90' >> .env
-```
-
-`AUDIT_ENABLED` is the master switch — off (or absent) means `emitAuditEvent`
-is a no-op and `data/audit/` is never created. `AUDIT_RETENTION_DAYS`: day
-files strictly older than the horizon are hard-deleted (unlinked) at boot and
-once per UTC day; `0` = keep forever; unset = 90.
-
-### 5. Build and test
-
-Run `build` before the tests — it's what catches a missed copy or a drifted
-import path across the whole composed tree:
-
-```bash
-pnpm run build
-pnpm exec vitest run src/audit src/cli/dispatch.audit.test.ts src/audit-wiring.test.ts
-pnpm test
-```
-
-### 6. Restart the service
-
-```bash
-source setup/lib/install-slug.sh
-launchctl kickstart -k gui/$(id -u)/$(launchd_label)   # macOS
-# systemctl --user restart $(systemd_unit)             # Linux
-```
-
-### 7. Verify (runtime smoke)
-
-```bash
-ncl groups list                     # any command — this one is now an audit event
-cat data/audit/$(date -u +%F).ndjson | tail -1
-ncl audit list --limit 5
-```
-
-The last line of the day-file is the `groups.list` event you just caused.
-
-## Reading it back
-
-```
-ncl audit list [--actor <id>] [--action <name-or-prefix>] [--resource <id-or-type>]
-               [--outcome success|failure|denied|pending|approved|rejected]
-               [--since 7d|24h|30m|ISO] [--until …] [--correlation <approval-id>]
-               [--limit N] [--format ndjson]
-```
-
-Newest first, default limit 100. `--action groups.config` matches the whole
-dotted subtree. `--format ndjson` streams the stored lines verbatim — pipe to
-a file for SIEM import. On a disabled box the command errors with
-`audit log is disabled — set AUDIT_ENABLED=true` rather than returning an
-empty list that would read as "no actions happened".
-
-The resource is deliberately **not** on the group-scope allowlist: audit
-spans agent groups, so group-scoped agents are refused before the handler
-(fails closed). Host callers and `cli_scope: global` agents only.
-
-## Redaction, failure posture, exporters
-
-- Every event's `details` passes a recursive key-pattern redactor
-  (`/(token|secret|key|password|credential|auth|bearer)/i` → `[REDACTED]`,
-  ~2 KB per-value cap) at the single emit seam.
-- Fail-open + loud: a failed append is `log.error`'d and the audited action
-  proceeds. At boot, an enabled box refuses to start if `data/audit/` isn't
-  writable.
-- In-process exporters register via `registerAuditHook` (from
-  `src/audit/index.js`) — post-write hooks that fire only after the local
-  append succeeds, so an external system can never be ahead of the source of
-  truth. Ship one as its own `/add-*` skill; declare `/add-audit` as its
-  dependency.
-
-## Troubleshooting
-
-- **Host won't start, banner names the audit directory** — `AUDIT_ENABLED=true`
-  but `data/audit/` isn't writable. Fix permissions or disable audit.
-- **`audit log is disabled — set AUDIT_ENABLED=true`** — the read-back guard;
-  enable in `.env` and restart.
-- **An agent gets "CLI access is scoped to this agent group" for `ncl audit`**
-  — by design; grant the group `cli_scope: global` only if it should read
-  cross-group history.
-- **`pnpm test` on an enabled box adds a few events to today's day-file** —
-  expected: the base dispatch tests drive real dispatches. Harmless noise;
-  the audit test suites themselves write only to temp dirs or capture buffers.
-
-## Removal
-
-See [REMOVE.md](REMOVE.md) — reverses every change; existing day-files are
-left in place (they're the operator's records).

.claude/skills/add-audit/add/src/audit-wiring.test.ts

@@ -1,143 +0,0 @@
-/**
- * Wiring tests for the /add-audit skill's two core edits — they go red if
- * either edit is deleted or drifts:
- *
- *  1. src/cli/dispatch.ts — the exported dispatch must be the composed
- *     `withAudit(dispatchInner)` (AST check: only the definition-site
- *     composition covers both transports AND the in-module approved replay).
- *  2. src/cli/resources/index.ts — the audit resource must register through
- *     the real barrel (behavior check), stay OFF the group-scope allowlist,
- *     and leave guard conformance clean.
- *
- * Plus the emit invariant the module's discipline rests on: emitAuditEvent
- * appears only in src/audit/ and *.audit.ts adapter files.
- */
-import fs from 'fs';
-import path from 'path';
-import ts from 'typescript';
-import { describe, expect, it } from 'vitest';
-
-// Same production barrels the guard conformance test loads (mirrors
-// src/guard/conformance.test.ts).
-import './cli/commands/index.js';
-import './modules/index.js';
-import './cli/delivery-action.js';
-import './cli/dispatch.js';
-
-import { commandGuard, GROUP_SCOPE_RESOURCES, lookup } from './cli/registry.js';
-import { getApprovalHandler } from './modules/approvals/primitive.js';
-import { listGuardedActions } from './guard/index.js';
-
-describe('audit resource registration (barrel wiring)', () => {
-  it('registers audit-list through the real resource barrel', () => {
-    const cmd = lookup('audit-list');
-    expect(cmd).toBeDefined();
-    expect(cmd?.action).toBe('audit.list');
-    expect(cmd?.access).toBe('open');
-  });
-
-  it('derives a guard-catalog entry for the audit command', () => {
-    const guard = commandGuard('audit-list');
-    expect(guard.action).toBe('audit.list');
-  });
-
-  it('is NOT on the group-scope allowlist — group-scoped agents fail closed', () => {
-    expect(GROUP_SCOPE_RESOURCES.has('audit')).toBe(false);
-  });
-
-  it('leaves guard conformance clean with the audit resource registered', () => {
-    // The invariant guard conformance checks: every holding action pairs with a
-    // registered approve continuation. audit.list is `open` (never holds), so
-    // registering the resource can't introduce a gap — this pins that.
-    const dangling = listGuardedActions()
-      .filter((spec) => spec.grantActionName)
-      .filter((spec) => !getApprovalHandler(spec.grantActionName as string));
-    expect(dangling.map((s) => s.action)).toEqual([]);
-  });
-});
-
-describe('dispatch composition (AST wiring)', () => {
-  const source = fs.readFileSync(path.resolve('src/cli/dispatch.ts'), 'utf8');
-  const sf = ts.createSourceFile('dispatch.ts', source, ts.ScriptTarget.Latest, true);
-
-  const hasExportModifier = (node: ts.HasModifiers): boolean =>
-    (ts.getModifiers(node) ?? []).some((m) => m.kind === ts.SyntaxKind.ExportKeyword);
-
-  let importsWithAudit = false;
-  let innerDeclaredUnexported = false;
-  let exportsWrappedDispatch = false;
-  let exportsUnwrappedDispatchFn = false;
-
-  sf.forEachChild((node) => {
-    if (
-      ts.isImportDeclaration(node) &&
-      ts.isStringLiteral(node.moduleSpecifier) &&
-      node.moduleSpecifier.text === './dispatch.audit.js'
-    ) {
-      const named = node.importClause?.namedBindings;
-      if (named && ts.isNamedImports(named) && named.elements.some((e) => e.name.text === 'withAudit')) {
-        importsWithAudit = true;
-      }
-    }
-    if (ts.isFunctionDeclaration(node) && node.name?.text === 'dispatchInner') {
-      innerDeclaredUnexported = !hasExportModifier(node);
-    }
-    if (ts.isFunctionDeclaration(node) && node.name?.text === 'dispatch' && hasExportModifier(node)) {
-      exportsUnwrappedDispatchFn = true;
-    }
-    if (ts.isVariableStatement(node) && hasExportModifier(node)) {
-      for (const decl of node.declarationList.declarations) {
-        if (
-          ts.isIdentifier(decl.name) &&
-          decl.name.text === 'dispatch' &&
-          decl.initializer &&
-          ts.isCallExpression(decl.initializer) &&
-          ts.isIdentifier(decl.initializer.expression) &&
-          decl.initializer.expression.text === 'withAudit' &&
-          decl.initializer.arguments.length === 1 &&
-          ts.isIdentifier(decl.initializer.arguments[0]) &&
-          decl.initializer.arguments[0].text === 'dispatchInner'
-        ) {
-          exportsWrappedDispatch = true;
-        }
-      }
-    }
-  });
-
-  it('imports withAudit from the audit adapter', () => {
-    expect(importsWithAudit).toBe(true);
-  });
-
-  it('keeps the inner dispatcher unexported (the guarded path is the only path)', () => {
-    expect(innerDeclaredUnexported).toBe(true);
-  });
-
-  it('exports dispatch as withAudit(dispatchInner)', () => {
-    expect(exportsWrappedDispatch).toBe(true);
-    expect(exportsUnwrappedDispatchFn).toBe(false);
-  });
-});
-
-describe('emit invariant', () => {
-  it('emitAuditEvent appears only in src/audit/ and *.audit.ts files', () => {
-    const srcRoot = path.resolve('src');
-    const offenders: string[] = [];
-    const walk = (dir: string): void => {
-      for (const entry of fs.readdirSync(dir, { withFileTypes: true })) {
-        const full = path.join(dir, entry.name);
-        if (entry.isDirectory()) {
-          walk(full);
-          continue;
-        }
-        if (!entry.name.endsWith('.ts')) continue;
-        const rel = path.relative(srcRoot, full).split(path.sep).join('/');
-        if (rel === 'audit-wiring.test.ts') continue; // this file names the symbol
-        if (rel.startsWith('audit/')) continue;
-        if (/\.audit(\.test)?\.ts$/.test(rel)) continue;
-        if (fs.readFileSync(full, 'utf8').includes('emitAuditEvent')) offenders.push(rel);
-      }
-    };
-    walk(srcRoot);
-    expect(offenders).toEqual([]);
-  });
-});

.claude/skills/add-audit/add/src/audit/config.ts

@@ -1,30 +0,0 @@
-/**
- * Audit env config (installed by /add-audit) — the two audit vars, read the
- * same way src/config.ts reads every host setting (readEnvFile from .env,
- * with process.env taking precedence). Kept audit-owned so installing the
- * skill never edits core config.ts: the feature's whole footprint in core is
- * the dispatch composition in dispatch.ts and the resource-barrel import.
- */
-import { readEnvFile } from '../env.js';
-
-const envConfig = readEnvFile(['AUDIT_ENABLED', 'AUDIT_RETENTION_DAYS']);
-
-/**
- * Master switch. Off by default — nothing is persisted (and data/audit/ is
- * never created) until an operator sets AUDIT_ENABLED=true.
- */
-export const AUDIT_ENABLED = (process.env.AUDIT_ENABLED || envConfig.AUDIT_ENABLED) === 'true';
-
-/**
- * Day-file retention horizon in days; consulted only when audit is enabled.
- * Unset or unparseable → 90. An explicit 0 (or negative) = keep forever.
- */
-function parseRetentionDays(raw: string | undefined): number {
-  if (raw === undefined || raw.trim() === '') return 90;
-  const n = Number.parseInt(raw, 10);
-  return Number.isNaN(n) ? 90 : n;
-}
-
-export const AUDIT_RETENTION_DAYS = parseRetentionDays(
-  process.env.AUDIT_RETENTION_DAYS || envConfig.AUDIT_RETENTION_DAYS,
-);

.claude/skills/add-audit/add/src/audit/index.ts

@@ -1,18 +0,0 @@
-/**
- * Opt-in local audit log — installed by /add-audit.
- *
- * This directory is a domain-free leaf: the event schema, the emit seam, the
- * store, the reader, post-write hooks, and shared vocabulary. What gets
- * audited — and how each domain describes itself — lives in the domain-owned
- * `*.audit.ts` adapter files next to the code they observe. Business logic
- * contains zero audit calls.
- *
- * emitAuditEvent is deliberately NOT re-exported here: adapters import it
- * from './emit.js' directly, and only src/audit/ + `*.audit.ts` may call it.
- */
-export * from './types.js';
-export { redactDetails } from './redact.js';
-export { AUDIT_DIR } from './store.js';
-export { AUDIT_ENABLED, AUDIT_RETENTION_DAYS } from './config.js';
-export { initAuditLog, maintainAudit } from './init.js';
-export { type AuditHook, registerAuditHook } from './hooks.js';

.claude/skills/add-audit/add/src/audit/init.ts

@@ -1,54 +0,0 @@
-/**
- * Boot-time audit wiring, self-contained (installed by /add-audit).
- *
- * initAuditLog() runs at module load of the CLI audit adapter
- * (cli/dispatch.audit.ts) — i.e. during the host's barrel phase, before the
- * CLI server or any delivery poll accepts work — because dispatch.ts, which
- * both transports import, composes withAudit at module scope. When enabled:
- * assert data/audit/ is writable (refusing to start beats running with a
- * silent audit gap), run the boot prune, start the registered post-write
- * hooks, and arm the maintenance timer.
- *
- * The timer owns the daily cadence in-module (checked hourly; the prune
- * itself fires at most once per UTC day) so installing the skill touches
- * dispatch.ts and the resource barrel only — no host-sweep edit. It is
- * unref'd: it never keeps the process alive.
- */
-import { log } from '../log.js';
-import { onShutdown } from '../response-registry.js';
-import { AUDIT_ENABLED, AUDIT_RETENTION_DAYS } from './config.js';
-import { initAuditHooks, maintainAuditHooks, shutdownAuditHooks } from './hooks.js';
-import { assertAuditWritable, AUDIT_DIR, markPrunedToday, pruneAuditLog, pruneAuditLogIfDue } from './store.js';
-
-const MAINTENANCE_INTERVAL_MS = 60 * 60 * 1000;
-
-let initialized = false;
-
-export function initAuditLog(): void {
-  if (!AUDIT_ENABLED || initialized) return;
-  initialized = true;
-  try {
-    assertAuditWritable();
-  } catch (err) {
-    throw new Error(
-      `AUDIT_ENABLED=true but the audit directory is not writable: ${AUDIT_DIR} (${err instanceof Error ? err.message : String(err)})`,
-      { cause: err },
-    );
-  }
-  pruneAuditLog();
-  markPrunedToday();
-  initAuditHooks(); // throw → boot fails, same posture as the writability assert
-  onShutdown(() => shutdownAuditHooks());
-  setInterval(maintainAudit, MAINTENANCE_INTERVAL_MS).unref();
-  log.info('Audit log enabled', { dir: AUDIT_DIR, retentionDays: AUDIT_RETENTION_DAYS });
-}
-
-/**
- * One maintenance tick: retention prune (throttled to once per UTC day
- * internally) plus every hook's periodic maintenance. No-op when audit is
- * disabled. Exported so a future scheduler can drive it too.
- */
-export function maintainAudit(): void {
-  pruneAuditLogIfDue();
-  if (AUDIT_ENABLED) maintainAuditHooks();
-}

.claude/skills/add-audit/add/src/audit/vocab.ts

@@ -1,39 +0,0 @@
-/**
- * Domain-free event vocabulary — actor and origin constructors shared by the
- * domain-owned `*.audit.ts` adapters (the CLI adapter today; approval and
- * channel adapters attach here in later increments). Pure derivation; nothing
- * here writes the log.
- *
- * Leaf rule: this module (like the rest of src/audit/) may depend on node,
- * config/log, shared types, and the db read layer — never on src/cli/* or
- * src/modules/*. Domain-specific mapping (CLI resources, approval payloads)
- * lives in the adapter file of the domain that owns it.
- */
-import os from 'os';
-
-import { getMessagingGroup } from '../db/messaging-groups.js';
-import type { AuditOrigin } from './types.js';
-
-/**
- * Host callers stamp `host:<install user>` daemon-side: the ncl socket is
- * 0600 and owned by the install user, so the identity is accurate by
- * construction without peer credentials.
- */
-export function hostUser(): string {
-  try {
-    return os.userInfo().username;
-    // eslint-disable-next-line no-catch-all/no-catch-all -- os.userInfo throws on exotic hosts; a fallback actor id beats no audit event
-  } catch {
-    return process.env.USER || 'unknown';
-  }
-}
-
-export function containerOrigin(sessionId: string, messagingGroupId: string | null): AuditOrigin {
-  const origin: AuditOrigin = { transport: 'container', session_id: sessionId };
-  if (messagingGroupId) {
-    origin.messaging_group_id = messagingGroupId;
-    const channel = getMessagingGroup(messagingGroupId)?.channel_type;
-    if (channel) origin.channel = channel;
-  }
-  return origin;
-}

.claude/skills/add-audit/add/src/cli/dispatch.audit.ts

@@ -1,238 +0,0 @@
-/**
- * CLI audit adapter (installed by /add-audit) — owns how the dispatcher
- * describes itself to the audit log: the dispatch middleware plus the
- * CLI-specific actor/origin/resource mapping. Composed in dispatch.ts as
- * `export const dispatch = withAudit(dispatchInner)`; business logic there
- * contains zero audit calls.
- *
- * Loading this module also boots the audit log (writability assert, boot
- * prune, hook lifecycle, maintenance timer): dispatch.ts is imported by both
- * transports during the host's barrel phase, so initAuditLog() runs before
- * any command is accepted — and an enabled box with an unwritable
- * data/audit/ refuses to start.
- */
-import { emitAuditEvent } from '../audit/emit.js';
-import { initAuditLog } from '../audit/init.js';
-import { type AuditActor, type AuditOrigin, type AuditOutcome, type AuditResource } from '../audit/types.js';
-import { containerOrigin, hostUser } from '../audit/vocab.js';
-import { getContainerConfig } from '../db/container-configs.js';
-import { getPendingApprovalsByAction } from '../db/sessions.js';
-import type { PendingApproval } from '../types.js';
-import { getResource } from './crud.js';
-import type { CallerContext, RequestFrame, ResponseFrame } from './frame.js';
-import { type CommandDef, lookup } from './registry.js';
-
-initAuditLog();
-
-// ── CLI mapping ──
-
-/**
- * Host callers stamp `host:<install user>` daemon-side (the ncl socket is
- * 0600 and owned by the install user); container callers are their agent group.
- */
-export function actorForCaller(ctx: CallerContext): AuditActor {
-  return ctx.caller === 'host' ? { type: 'human', id: `host:${hostUser()}` } : { type: 'agent', id: ctx.agentGroupId };
-}
-
-export function originForCaller(ctx: CallerContext): AuditOrigin {
-  if (ctx.caller === 'host') return { transport: 'socket' };
-  return containerOrigin(ctx.sessionId, ctx.messagingGroupId || null);
-}
-
-/**
- * Frame-level args use `--hyphen-keys`; recorded details use the same
- * underscore form the parsed handlers see. Mirrors crud's normalizeArgs
- * (kept local so audit doesn't depend on a module tests commonly mock).
- */
-export function normalizeArgKeys(raw: Record<string, unknown>): Record<string, unknown> {
-  const out: Record<string, unknown> = {};
-  for (const [k, v] of Object.entries(raw)) {
-    out[k.replace(/-/g, '_')] = v;
-  }
-  return out;
-}
-
-/** CLI resource plural → audit resource type, where the singular isn't it. */
-const RESOURCE_TYPE_OVERRIDES: Record<string, string> = {
-  groups: 'agent_group',
-  'messaging-groups': 'messaging_group',
-  'dropped-messages': 'dropped_message',
-  'user-dms': 'user_dm',
-};
-
-/**
- * Derive touched/attempted resources from a command's effective args. Generic
- * by design: `id` → the command's own resource, group/user args → their
- * types, and a bare `{type}` entry when nothing else is known (a denied
- * `users list` still names what was attempted).
- */
-export function resourcesForCli(cmd: CommandDef, args: Record<string, unknown>): AuditResource[] {
-  if (!cmd.resource) return [];
-  const type = RESOURCE_TYPE_OVERRIDES[cmd.resource] ?? getResource(cmd.resource)?.name ?? cmd.resource;
-
-  const out: AuditResource[] = [];
-  const push = (t: string, id: unknown): void => {
-    if (typeof id !== 'string' || !id) return;
-    if (!out.some((r) => r.type === t && r.id === id)) out.push({ type: t, id });
-  };
-  push(type, args.id);
-  push('agent_group', args.agent_group_id ?? args.group);
-  push('user', args.user);
-  if (out.length === 0) out.push({ type });
-  return out;
-}
-
-// ── Dispatch mechanics, mirrored for the record ──
-// Dispatch resolves the command and auto-fills args on a local copy of the
-// frame that never leaves it, so the middleware mirrors the two documented
-// mechanics below. The copies are mechanical, and drift only ever degrades a
-// record's detail (a fallback action name, a missing auto-filled arg) — never
-// dispatch behavior, and never an outcome.
-
-/**
- * Mirror of dispatch's command resolution: exact lookup, then the longest
- * registered dash-prefix with the remainder recorded as --id.
- */
-function resolveForRecord(req: RequestFrame): { cmd?: CommandDef; args: Record<string, unknown> } {
-  const direct = lookup(req.command);
-  if (direct) return { cmd: direct, args: req.args };
-  let shortened = req.command;
-  let idx: number;
-  while ((idx = shortened.lastIndexOf('-')) > 0) {
-    shortened = shortened.slice(0, idx);
-    const fallback = lookup(shortened);
-    if (fallback) {
-      const tail = req.command.slice(shortened.length + 1);
-      return { cmd: fallback, args: { ...req.args, id: req.args.id ?? tail } };
-    }
-  }
-  return { args: req.args };
-}
-
-/**
- * Mirror of dispatch's group-scope arg auto-fill, so the record shows the
- * effective args the handler saw (e.g. which agent group a bare
- * `sessions list` actually listed).
- */
-function effectiveArgs(
-  cmd: CommandDef | undefined,
-  args: Record<string, unknown>,
-  ctx: CallerContext,
-): Record<string, unknown> {
-  if (ctx.caller !== 'agent') return args;
-  if ((getContainerConfig(ctx.agentGroupId)?.cli_scope ?? 'group') !== 'group') return args;
-  const fill: Record<string, unknown> = {
-    agent_group_id: args.agent_group_id ?? ctx.agentGroupId,
-    group: args.group ?? ctx.agentGroupId,
-  };
-  if (cmd?.resource === 'groups' || cmd?.resource === 'destinations') {
-    fill.id = args.id ?? ctx.agentGroupId;
-  }
-  return { ...args, ...fill };
-}
-
-/**
- * CLI args arrive as strings, so a JSON-object/array value (e.g.
- * `--env '{"NOTION_TOKEN":"…"}'`) would reach the redactor as one opaque
- * string under an innocent key and its inner secret keys would survive.
- * Recording the parsed form lets the redactor walk inside — the audit log's
- * "secrets never land" property depends on it for exactly this flow.
- */
-function parseJsonishValues(args: Record<string, unknown>): Record<string, unknown> {
-  const out: Record<string, unknown> = {};
-  for (const [k, v] of Object.entries(args)) {
-    if (typeof v === 'string' && (v.startsWith('{') || v.startsWith('['))) {
-      try {
-        out[k] = JSON.parse(v);
-        continue;
-        // eslint-disable-next-line no-catch-all/no-catch-all -- not JSON after all: record the string as-is
-      } catch {
-        /* fall through */
-      }
-    }
-    out[k] = v;
-  }
-  return out;
-}
-
-/**
- * The approval row a hold just created for this frame — it gives the pending
- * event the same correlation_id the approved replay will carry as its guard
- * grant. requestApproval keeps the minted id internal, so the row is
- * recovered by the frame id it stored in its payload; no row (e.g. no
- * configured approver) → the hold is still recorded, uncorrelated.
- */
-function holdApprovalIdFor(frameId: string): string | null {
-  const rows = getPendingApprovalsByAction('cli_command');
-  for (let i = rows.length - 1; i >= 0; i--) {
-    try {
-      const payload = JSON.parse(rows[i].payload) as { frame?: { id?: string } };
-      if (payload.frame?.id === frameId) return rows[i].approval_id;
-      // eslint-disable-next-line no-catch-all/no-catch-all -- a row with an unparseable payload is simply not this frame's hold
-    } catch {
-      continue;
-    }
-  }
-  return null;
-}
-
-// ── The dispatch middleware ──
-
-type DispatchInner = (
-  req: RequestFrame,
-  ctx: CallerContext,
-  opts?: { grant?: PendingApproval },
-) => Promise<ResponseFrame>;
-
-/**
- * Dispatch middleware — the exported `dispatch` is the wrapped function, so
- * the socket server, the container delivery-action, and the in-module
- * approved replay are all covered by the one composition.
- *
- * Outcome derives from the response frame: ok → success, forbidden → denied
- * (captures pre-handler scope denials), approval-pending → pending (the
- * record of a hold), anything else → failure. Correlation is the approval id:
- * an approved replay carries the approval row as its guard grant
- * (opts.grant), and a fresh hold is correlated by recovering the row it just
- * created — so `--correlation <approval-id>` returns the whole gated chain.
- */
-export function withAudit(inner: DispatchInner): DispatchInner {
-  return async (req, ctx, opts = {}) => {
-    const res = await inner(req, ctx, opts);
-    emitAuditEvent(() => {
-      const resolved = resolveForRecord(req);
-      const cmd = resolved.cmd;
-      const pending = !res.ok && res.error.code === 'approval-pending';
-      const outcome: AuditOutcome = res.ok
-        ? 'success'
-        : res.error.code === 'forbidden'
-          ? 'denied'
-          : pending
-            ? 'pending'
-            : 'failure';
-      // A denial records the attempt as asked (raw args): nothing ran, so the
-      // auto-fill never conceptually happened — and a cross-group attempt
-      // must show the foreign id the caller passed, not a filled-in own-group.
-      const args = normalizeArgKeys(outcome === 'denied' ? resolved.args : effectiveArgs(cmd, resolved.args, ctx));
-      const correlationId = opts.grant?.approval_id ?? (pending ? holdApprovalIdFor(req.id) : null);
-      const details: Record<string, unknown> = parseJsonishValues(args);
-      if (!res.ok && !pending) {
-        details.error = res.error.code;
-        details.reason = res.error.message;
-      }
-      if (!cmd) details.command = req.command;
-      const resources = cmd ? resourcesForCli(cmd, args) : [];
-      if (correlationId) resources.push({ type: 'approval', id: correlationId });
-      return {
-        actor: actorForCaller(ctx),
-        origin: originForCaller(ctx),
-        action: cmd ? (cmd.action ?? `cli.${cmd.name}`) : 'cli.unknown-command',
-        resources,
-        outcome,
-        correlationId,
-        details,
-      };
-    });
-    return res;
-  };
-}

.claude/skills/add-clidash/add/tools/clidash/activity.js

@@ -18,12 +18,6 @@ function normTs(ts) {
   return `${ts.replace(' ', 'T')}Z`;
 }
 
-// Local calendar day "YYYY-MM-DD" — chart labels are read by a human, so
-// bucket by the server's local day, not the UTC date prefix.
-function localDay(date) {
-  return date.toLocaleDateString('sv-SE');
-}
-
 function readTable(dbPath, table) {
   let db;
   try {
@@ -34,7 +28,7 @@ function readTable(dbPath, table) {
     for (const r of rows) {
       const ts = normTs(r.timestamp);
       if (!ts) continue;
-      const day = localDay(new Date(ts));
+      const day = ts.slice(0, 10); // ISO date prefix
       byDay.set(day, (byDay.get(day) ?? 0) + 1);
       if (last === null || ts > last) last = ts;
     }
@@ -58,12 +52,12 @@ function listDirs(path) {
  * Aggregate message activity across all session DBs under `sessionsRoot`.
  * @returns {{ sessions: Array, series: Array<{date,in,out}> }}
  *   sessions — per session: { agent_group_id, session_id, in, out, lastActivity }
- *   series   — one bucket per day for the last `days` days (local time, newest last)
+ *   series   — one bucket per day for the last `days` days (UTC, newest last)
  */
 export function collectActivity(sessionsRoot, days, now) {
   const dates = [];
   for (let i = days - 1; i >= 0; i--) {
-    dates.push(localDay(new Date(now.getTime() - i * 86_400_000)));
+    dates.push(new Date(now.getTime() - i * 86_400_000).toISOString().slice(0, 10));
   }
   const series = new Map(dates.map((d) => [d, { date: d, in: 0, out: 0 }]));
   const sessions = [];

.claude/skills/add-clidash/add/tools/clidash/public/app.js

@@ -71,14 +71,6 @@ function icon(name) {
 
 const ISO_RE = /^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}/;
 
-// Local wall time "YYYY-MM-DD HH:mm" — the raw ISO string is UTC; slicing it
-// would display UTC wall time with no marker, masquerading as local.
-function absTime(iso) {
-  const d = new Date(iso);
-  if (Number.isNaN(d.getTime())) return iso;
-  return d.toLocaleString('sv-SE', { year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', hour12: false });
-}
-
 function relTime(iso) {
   const ms = Date.now() - new Date(iso).getTime();
   if (Number.isNaN(ms)) return iso;
@@ -135,7 +127,7 @@ function cellFor(value) {
   if (f.cls === 'null') return el('td', { class: 'null' }, 'null');
   if (f.iso) {
     return el('td', {}, el('span', { class: 'reltime', title: f.iso }, [
-      relTime(f.iso), el('span', { class: 'abs' }, absTime(f.iso)),
+      relTime(f.iso), el('span', { class: 'abs' }, f.iso.slice(0, 16).replace('T', ' ')),
     ]));
   }
   if (f.text.length > 42) {
@@ -150,7 +142,7 @@ function kvRows(obj) {
   return Object.entries(obj ?? {}).map(([k, v]) => {
     let valEl;
     if (v && typeof v === 'object') valEl = el('pre', { class: 'kv-json' }, JSON.stringify(v, null, 2));
-    else if (typeof v === 'string' && ISO_RE.test(v)) valEl = el('span', { class: 'reltime', title: v }, `${relTime(v)}  (${absTime(v)})`);
+    else if (typeof v === 'string' && ISO_RE.test(v)) valEl = el('span', { class: 'reltime', title: v }, `${relTime(v)}  (${v.slice(0, 16).replace('T', ' ')})`);
     else if (v === null || v === undefined) valEl = el('span', { class: 'null' }, 'null');
     else valEl = el('span', {}, String(v));
     return el('div', { class: 'kv-row' }, [el('span', { class: 'kv-key' }, k), valEl]);

.claude/skills/add-clidash/add/tools/clidash/test/activity-server.test.js

@@ -11,14 +11,9 @@ before(() => {
   root = mkdtempSync(join(tmpdir(), 'clidash-actsrv-'));
   mkdirSync(join(root, 'ag-1', 'sess-1'), { recursive: true });
   const mk = (p, t, ts) => { const db = new DatabaseSync(p); db.exec(`CREATE TABLE ${t}(id TEXT, timestamp TEXT)`); const i = db.prepare(`INSERT INTO ${t} VALUES (?,?)`); ts.forEach((x, n) => i.run(String(n), x)); db.close(); };
-  // Seed with instants moments ago: they land in the LOCAL-today bucket
-  // (series.at(-1)) regardless of the machine's timezone.
-  const now = Date.now();
-  mk(join(root, 'ag-1', 'sess-1', 'inbound.db'), 'messages_in', [
-    new Date(now - 120_000).toISOString(),
-    new Date(now - 60_000).toISOString(),
-  ]);
-  mk(join(root, 'ag-1', 'sess-1', 'outbound.db'), 'messages_out', [new Date(now - 90_000).toISOString()]);
+  const today = new Date().toISOString().slice(0, 10);
+  mk(join(root, 'ag-1', 'sess-1', 'inbound.db'), 'messages_in', [`${today} 09:00:00`, `${today} 10:00:00`]);
+  mk(join(root, 'ag-1', 'sess-1', 'outbound.db'), 'messages_out', [`${today} 09:05:00`]);
 });
 after(() => rmSync(root, { recursive: true, force: true }));
 

.claude/skills/add-clidash/add/tools/clidash/test/activity.test.js

@@ -45,30 +45,20 @@ test('collectActivity: per-session in/out totals + last activity', () => {
   assert.equal(s2.out, 0);
 });
 
-// Buckets are LOCAL calendar days — derive expectations with the same
-// mapping so the assertions hold in any machine timezone.
-const day = (t) => new Date(t).toLocaleDateString('sv-SE');
-
 test('collectActivity: series has one bucket per day for `days`, newest last', () => {
   const { series } = collectActivity(root, 14, NOW);
   assert.equal(series.length, 14);
-  assert.equal(series[0].date, day(new Date(NOW.getTime() - 13 * 86_400_000)));
-  assert.equal(series[13].date, day(NOW));
+  assert.equal(series[0].date, '2026-06-01');
+  assert.equal(series[13].date, '2026-06-14');
 });
 
 test('collectActivity: counts land in the right day buckets', () => {
   const { series } = collectActivity(root, 14, NOW);
   const byDate = Object.fromEntries(series.map((d) => [d.date, d]));
-  const expIn = {};
-  const expOut = {};
-  for (const t of ['2026-06-14T09:01:23Z', '2026-06-14T10:00:00Z', '2026-06-13T08:00:00Z']) {
-    expIn[day(t)] = (expIn[day(t)] ?? 0) + 1;
-  }
-  for (const t of ['2026-06-14T09:05:00Z', '2026-06-14T10:05:00Z']) {
-    expOut[day(t)] = (expOut[day(t)] ?? 0) + 1;
-  }
-  for (const [d, n] of Object.entries(expIn)) assert.equal(byDate[d].in, n);
-  for (const [d, n] of Object.entries(expOut)) assert.equal(byDate[d].out, n);
+  assert.equal(byDate['2026-06-14'].in, 2);
+  assert.equal(byDate['2026-06-14'].out, 2);
+  assert.equal(byDate['2026-06-13'].in, 1);
+  assert.equal(byDate['2026-06-13'].out, 0);
 });
 
 test('collectActivity: messages outside the window are counted in totals but not the series', () => {

.claude/skills/add-dashboard/resources/dashboard-pusher.ts

@@ -427,20 +427,12 @@ function collectContextWindows() {
   return results;
 }
 
-// "YYYY-MM-DDTHH" in the host's local time — the chart's hour labels are read
-// by a human, so bucket by local hour, not UTC. sv-SE renders "YYYY-MM-DD HH".
-function localHourKey(d: Date): string {
-  return d
-    .toLocaleString('sv-SE', { year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', hour12: false })
-    .replace(' ', 'T');
-}
-
 function collectActivity() {
   const now = Date.now();
   const buckets: Record<string, { inbound: number; outbound: number }> = {};
 
   for (let i = 0; i < 24; i++) {
-    const key = localHourKey(new Date(now - i * 3600000));
+    const key = new Date(now - i * 3600000).toISOString().slice(0, 13);
     buckets[key] = { inbound: 0, outbound: 0 };
   }
 
@@ -461,7 +453,7 @@ function collectActivity() {
             const table = direction === 'outbound' ? 'messages_out' : 'messages_in';
             const rows = db.prepare(`SELECT timestamp FROM ${table} WHERE timestamp > ?`).all(cutoff) as { timestamp: string }[];
             for (const row of rows) {
-              const key = localHourKey(new Date(row.timestamp));
+              const key = row.timestamp.slice(0, 13);
               if (buckets[key]) buckets[key][direction]++;
             }
             db.close();

.claude/skills/add-deltachat/SKILL.md

@@ -167,14 +167,7 @@ pnpm exec tsx scripts/init-first-agent.ts \
 
 ### Groups
 
-Add the bot email to a DeltaChat group. When any member sends a message, the router creates a `messaging_groups` row with `is_group = 1`. Run `/manage-channels` to wire it to an agent group, or wire it directly with `ncl` — **the host service must be running** (`ncl` connects to it over a Unix socket):
-
-```bash
-# Engage mode/pattern default to the DeltaChat adapter's declared channel
-# defaults — for DeltaChat groups that's a name pattern (the platform has no
-# mention metadata), so the agent responds when addressed by name.
-ncl wirings create --messaging-group-id <mg-id> --agent-group-id <ag-id>
-```
+Add the bot email to a DeltaChat group. When any member sends a message, the router creates a `messaging_groups` row with `is_group = 1`. Run `/manage-channels` to wire it to an agent group.
 
 ## Next Steps
 
@@ -191,7 +184,7 @@ Otherwise, run `/init-first-agent` to create an agent and wire it to your DeltaC
 - **user-id-format**: `deltachat:{email}` — the contact's email address
 - **how-to-find-id**: Send a message from DeltaChat to the bot email, then query `messaging_groups` as shown above
 - **typical-use**: Personal assistant over DeltaChat DMs; small groups where participants use DeltaChat
-- **default-isolation**: One agent per bot identity. Multiple chats with the same operator can share an agent group; groups with other people should typically get their own agent group (the default `shared` session mode already gives each messaging group its own session)
+- **default-isolation**: One agent per bot identity. Multiple chats with the same operator can share an agent group; groups with other people should typically use `isolated` session mode
 
 ### Features
 

.claude/skills/add-emacs/SKILL.md

@@ -105,14 +105,6 @@ pnpm exec tsx setup/index.ts --step register -- \
 
 `agent-shared` puts Emacs messages in the same session as any other channel wired to the same agent group — so a conversation you started in Telegram continues in Emacs. Use `shared` to keep an independent Emacs thread with the same workspace, or a new `--folder` for a dedicated Emacs-only agent.
 
-Alternatively create the rows with `ncl` — **the host service must be running** (`ncl` connects to it over a Unix socket). Engage mode/pattern and `unknown_sender_policy` default to the Emacs adapter's declared channel defaults:
-
-```bash
-ncl messaging-groups create --channel-type emacs --platform-id "default" --name "Emacs"
-ncl wirings create --messaging-group-id <mg-id-from-above> --agent-group-id <ag-id> \
-  --session-mode agent-shared
-```
-
 ## Configure Emacs
 
 `nanoclaw.el` needs only Emacs 27.1+ builtins (`url`, `json`, `org`) — no package manager.

.claude/skills/add-gcal-tool/REMOVE.md

@@ -18,7 +18,7 @@ There is no `ncl groups config remove-mount` verb yet (tracked in [#2395](https:
 pnpm exec tsx scripts/q.ts data/v2.db "UPDATE container_configs \
   SET additional_mounts = (SELECT json_group_array(value) FROM json_each(additional_mounts) \
                            WHERE json_extract(value, '\$.containerPath') != '.calendar-mcp'), \
-      updated_at = strftime('%Y-%m-%dT%H:%M:%fZ','now') \
+      updated_at = datetime('now') \
   WHERE agent_group_id = '<group-id>';"
 ```
 

.claude/skills/add-gcal-tool/SKILL.md

@@ -168,11 +168,11 @@ HOST_PATH="$HOME/.calendar-mcp"
 MOUNT=$(jq -cn --arg h "$HOST_PATH" '{hostPath:$h, containerPath:".calendar-mcp", readonly:false}')
 pnpm exec tsx scripts/q.ts data/v2.db "UPDATE container_configs \
   SET additional_mounts = json_insert(additional_mounts, '\$[#]', json('$MOUNT')), \
-      updated_at = strftime('%Y-%m-%dT%H:%M:%fZ','now') \
+      updated_at = datetime('now') \
   WHERE agent_group_id = '$GROUP_ID';"
 ```
 
-Run from your NanoClaw project root (where `data/v2.db` lives). The `$[#]` placeholder is SQLite JSON1's append-to-end notation; it's `\$`-escaped so bash doesn't arithmetic-expand it before sqlite sees it. `updated_at` is an ISO-with-Z string everywhere else in the schema (`new Date().toISOString()`), so stamp the same shape with `strftime` — plain `datetime('now')` would mix naive UTC strings into the column, and `strftime('%s','now')` epoch ints.
+Run from your NanoClaw project root (where `data/v2.db` lives). The `$[#]` placeholder is SQLite JSON1's append-to-end notation; it's `\$`-escaped so bash doesn't arithmetic-expand it before sqlite sees it. `updated_at` is ISO-string everywhere else in the schema, so use `datetime('now')` — not `strftime('%s','now')`, which would silently mix epoch ints into a column of YYYY-MM-DD HH:MM:SS strings.
 
 **Switch to `ncl groups config add-mount` once #2395 lands.** Update this skill at that time.
 

.claude/skills/add-github/SKILL.md

@@ -107,17 +107,16 @@ Ask the user: **Is this a private or public repo?**
 - **Private repo** — use `unknown_sender_policy: 'public'`. Only collaborators can comment anyway, so it's safe to let all comments through.
 - **Public repo** — use `unknown_sender_policy: 'strict'`. Only registered members can trigger the agent, preventing strangers from consuming agent resources. Add trusted collaborators as members (see below).
 
-Run `/manage-channels` to wire the GitHub channel to an agent group, or create the rows directly with `ncl`. **The host service must be running** — `ncl` connects to it over a Unix socket:
+Run `/manage-channels` to wire the GitHub channel to an agent group, or insert manually:
 
-```bash
-# Create messaging group (one per repo)
-ncl messaging-groups create --channel-type github --platform-id "github:owner/repo" \
-  --name "owner/repo" --is-group 1 --unknown-sender-policy <policy>
+```sql
+-- Create messaging group (one per repo)
+INSERT INTO messaging_groups (id, channel_type, platform_id, instance, name, is_group, unknown_sender_policy, created_at)
+VALUES ('mg-github-myrepo', 'github', 'github:owner/repo', 'github', 'owner/repo', 1, '<policy>', datetime('now'));
 
-# Wire to agent group (engage mode/pattern default to the GitHub adapter's
-# declared channel defaults; grab the mg id from the create output above)
-ncl wirings create --messaging-group-id <mg-id> --agent-group-id <your-agent-group-id> \
-  --session-mode per-thread
+-- Wire to agent group
+INSERT INTO messaging_group_agents (id, messaging_group_id, agent_group_id, trigger_rules, response_scope, session_mode, priority, created_at)
+VALUES ('mga-github-myrepo', 'mg-github-myrepo', '<your-agent-group-id>', '', 'all', 'per-thread', 10, datetime('now'));
 ```
 
 Replace `<policy>` with `public` or `strict` based on the user's choice above.
@@ -126,12 +125,14 @@ Replace `<policy>` with `public` or `strict` based on the user's choice above.
 
 When using `strict`, add each GitHub user who should be able to trigger the agent:
 
-```bash
-# Add user (kind = 'github', id = 'github:<numeric-user-id>')
-ncl users create --id "github:<user-id>" --kind github --display-name "<username>"
+```sql
+-- Add user (kind = 'github', id = 'github:<numeric-user-id>')
+INSERT OR IGNORE INTO users (id, kind, display_name, created_at)
+VALUES ('github:<user-id>', 'github', '<username>', datetime('now'));
 
-# Grant membership to the agent group
-ncl members add --user "github:<user-id>" --group "<agent-group-id>"
+-- Grant membership to the agent group
+INSERT OR IGNORE INTO agent_group_members (user_id, agent_group_id)
+VALUES ('github:<user-id>', '<agent-group-id>');
 ```
 
 To find a GitHub user's numeric ID: `gh api users/<username> --jq .id`

.claude/skills/add-gmail-tool/REMOVE.md

@@ -26,7 +26,7 @@ GROUP_ID='<group-id>'
 pnpm exec tsx scripts/q.ts data/v2.db "UPDATE container_configs \
   SET additional_mounts = (SELECT json_group_array(value) FROM json_each(additional_mounts) \
                            WHERE json_extract(value, '\$.containerPath') != '.gmail-mcp'), \
-      updated_at = strftime('%Y-%m-%dT%H:%M:%fZ','now') \
+      updated_at = datetime('now') \
   WHERE agent_group_id = '$GROUP_ID';"
 ```
 

.claude/skills/add-gmail-tool/SKILL.md

@@ -189,11 +189,11 @@ HOST_PATH="$HOME/.gmail-mcp"
 MOUNT=$(jq -cn --arg h "$HOST_PATH" '{hostPath:$h, containerPath:".gmail-mcp", readonly:false}')
 pnpm exec tsx scripts/q.ts data/v2.db "UPDATE container_configs \
   SET additional_mounts = json_insert(additional_mounts, '\$[#]', json('$MOUNT')), \
-      updated_at = strftime('%Y-%m-%dT%H:%M:%fZ','now') \
+      updated_at = datetime('now') \
   WHERE agent_group_id = '$GROUP_ID';"
 ```
 
-Run from your NanoClaw project root (where `data/v2.db` lives). The `$[#]` placeholder is SQLite JSON1's append-to-end notation; it's `\$`-escaped so bash doesn't arithmetic-expand it before sqlite sees it. `updated_at` is an ISO-with-Z string everywhere else in the schema (`new Date().toISOString()`), so stamp the same shape with `strftime` — plain `datetime('now')` would mix naive UTC strings into the column, and `strftime('%s','now')` epoch ints.
+Run from your NanoClaw project root (where `data/v2.db` lives). The `$[#]` placeholder is SQLite JSON1's append-to-end notation; it's `\$`-escaped so bash doesn't arithmetic-expand it before sqlite sees it. `updated_at` is ISO-string everywhere else in the schema, so use `datetime('now')` — not `strftime('%s','now')`, which would silently mix epoch ints into a column of YYYY-MM-DD HH:MM:SS strings.
 
 **Switch to `ncl groups config add-mount` once #2395 lands.** Update this skill at that time.
 

.claude/skills/add-linear/SKILL.md

@@ -115,20 +115,19 @@ Ask the user: **Is this a private or public Linear workspace?**
 - **Private workspace** — use `unknown_sender_policy: 'public'`. Only workspace members can comment.
 - **Public workspace** — use `unknown_sender_policy: 'strict'` and add trusted members (see GitHub skill for member registration example).
 
-Run `/manage-channels` to wire the Linear channel to an agent group, or create the rows directly with `ncl`. **The host service must be running** — `ncl` connects to it over a Unix socket:
+Run `/manage-channels` to wire the Linear channel to an agent group, or insert manually:
 
-```bash
-# Create messaging group (one per team)
-ncl messaging-groups create --channel-type linear --platform-id "linear:ENG" \
-  --name "Engineering" --is-group 1 --unknown-sender-policy <policy>
+```sql
+-- Create messaging group (one per team)
+INSERT INTO messaging_groups (id, channel_type, platform_id, instance, name, is_group, unknown_sender_policy, created_at)
+VALUES ('mg-linear-eng', 'linear', 'linear:ENG', 'linear', 'Engineering', 1, 'public', datetime('now'));
 
-# Wire to agent group (engage mode/pattern default to the Linear adapter's
-# declared channel defaults; grab the mg id from the create output above)
-ncl wirings create --messaging-group-id <mg-id> --agent-group-id <your-agent-group-id> \
-  --session-mode per-thread
+-- Wire to agent group
+INSERT INTO messaging_group_agents (id, messaging_group_id, agent_group_id, trigger_rules, response_scope, session_mode, priority, created_at)
+VALUES ('mga-linear-eng', 'mg-linear-eng', '<your-agent-group-id>', '', 'all', 'per-thread', 10, datetime('now'));
 ```
 
-Replace `<policy>` with `public` or `strict` based on the user's choice above. The `platform_id` must be `linear:<TEAM_KEY>` matching the `LINEAR_TEAM_KEY` env var. Use `per-thread` session mode so each issue comment thread gets its own agent session.
+The `platform_id` must be `linear:<TEAM_KEY>` matching the `LINEAR_TEAM_KEY` env var. Use `per-thread` session mode so each issue comment thread gets its own agent session.
 
 ## Next Steps
 

.claude/skills/add-signal/SKILL.md

@@ -220,21 +220,30 @@ Pass the `id` to `/init-first-agent` or `/manage-channels` to wire it to an agen
 
 ### Groups
 
-Add the Signal number to a group from your phone, send any message, then wire the resulting row the same way. Each group gets its own session with the default `shared` mode (one session per agent + messaging group). Create the wiring with `ncl` — **the host service must be running** (`ncl` connects to it over a Unix socket):
+Add the Signal number to a group from your phone, send any message, then wire the resulting row the same way. For isolated per-group sessions:
 
 ```bash
-# Engage mode/pattern default to the Signal adapter's declared channel defaults
-ncl wirings create --messaging-group-id mg-GROUPID --agent-group-id ag-AGENTID
+NOW=$(date -u +"%Y-%m-%dT%H:%M:%S.000Z")
+pnpm exec tsx scripts/q.ts data/v2.db "
+INSERT OR IGNORE INTO messaging_group_agents
+  (id, messaging_group_id, agent_group_id, session_mode, priority, created_at)
+VALUES
+  ('mga-'||hex(randomblob(8)), 'mg-GROUPID', 'ag-AGENTID', 'isolated', 0, '$NOW');
+"
 ```
 
 ### Grant user access
 
-New Signal users (including the owner's Signal identity) are silently dropped with `not_member` until granted access. After the user's first message appears in `messaging_groups` (host service running):
+New Signal users (including the owner's Signal identity) are silently dropped with `not_member` until granted access. After the user's first message appears in `messaging_groups`:
 
 ```bash
-ncl users create --id "signal:UUID" --kind signal --display-name "<name>"
-ncl roles grant --user "signal:UUID" --role owner
-ncl members add --user "signal:UUID" --group ag-AGENTID
+NOW=$(date -u +"%Y-%m-%dT%H:%M:%S.000Z")
+pnpm exec tsx scripts/q.ts data/v2.db "
+INSERT OR REPLACE INTO user_roles (user_id, role, agent_group_id, granted_by, granted_at)
+  VALUES ('signal:UUID', 'owner', NULL, 'system', '$NOW');
+INSERT OR IGNORE INTO agent_group_members (user_id, agent_group_id, added_by, added_at)
+  VALUES ('signal:UUID', 'ag-AGENTID', 'system', '$NOW');
+"
 ```
 
 Find the UUID from `messaging_groups.platform_id` or the `users` table.
@@ -255,7 +264,7 @@ Otherwise, run `/init-first-agent` to create an agent and wire it to your Signal
   - Group: `signal:{base64GroupId}` — base64-encoded GroupV2 ID
 - **how-to-find-id**: Send a message to the bot, then query `messaging_groups` as shown above
 - **typical-use**: Personal assistant via Signal DMs or small group chats
-- **default-isolation**: One agent per Signal account. Multiple chats with the same operator can share an agent group; groups with other people should typically get their own agent group (the default `shared` session mode already gives each messaging group its own session)
+- **default-isolation**: One agent per Signal account. Multiple chats with the same operator can share an agent group; groups with other people should typically use `isolated` session mode
 
 ### Features
 

.claude/skills/add-slack/SKILL.md

@@ -18,7 +18,6 @@ Skip to **Credentials** if all of these are already in place:
 - `src/channels/slack.ts` exists
 - `src/channels/slack-registration.test.ts` exists
 - `src/channels/index.ts` contains `import './slack.js';`
-- `container/skills/slack-formatting/SKILL.md` exists
 - `@chat-adapter/slack` is listed in `package.json` dependencies
 
 Otherwise continue. Every step below is safe to re-run.
@@ -34,15 +33,8 @@ git fetch origin channels
 ```bash
 git show origin/channels:src/channels/slack.ts                 > src/channels/slack.ts
 git show origin/channels:src/channels/slack-registration.test.ts > src/channels/slack-registration.test.ts
-mkdir -p container/skills/slack-formatting
-git show origin/channels:container/skills/slack-formatting/SKILL.md > container/skills/slack-formatting/SKILL.md
 ```
 
-The `slack-formatting` container skill is part of the channel payload: it
-reaches agents via `~/.claude/skills` (synced at spawn) and teaches Slack's
-mrkdwn syntax. Trunk does not ship it — without this copy step agents send
-Slack messages with generic markdown that renders literally.
-
 ### 3. Append the self-registration import
 
 Append to `src/channels/index.ts` (skip if the line is already present):

.claude/skills/add-wechat/SKILL.md

@@ -121,11 +121,9 @@ The bot is now connected as your WeChat account.
 
 A successful QR login alone isn't enough — the adapter still needs to be wired to an agent group before it can respond.
 
-**Prerequisite: the host service must be running.** The wire script creates the wiring through `ncl`, which talks to the running host over a Unix socket — there is no offline mode.
-
 ### 1. Trigger the first inbound message
 
-Have a different WeChat account send a message to the bot account. This auto-creates a `messaging_groups` row with the sender's `platform_id` and the `unknown_sender_policy` the WeChat adapter declares.
+Have a different WeChat account send a message to the bot account. This auto-creates a `messaging_groups` row with the sender's `platform_id`.
 
 ### 2. Run the wire script
 
@@ -133,9 +131,9 @@ Have a different WeChat account send a message to the bot account. This auto-cre
 pnpm exec tsx .claude/skills/add-wechat/scripts/wire-dm.ts
 ```
 
-Interactive flow: the script lists all unwired WeChat messaging groups, asks which agent group to wire it to, and runs `ncl wirings create` — engage mode/pattern and priority come from the WeChat adapter's declared channel defaults, so a wiring created here matches one created by `/manage-channels` or the approval-card flow.
+Interactive flow: the script lists all unwired WeChat messaging groups, asks which agent group to wire it to, and creates the `messaging_group_agents` row with sensible defaults (sender policy `request_approval`, session mode `shared`).
 
-With `request_approval` as the sender policy, the next DM from a stranger fires an approval card to the admin — admin taps Approve/Deny, approved users are added as members and their queued message replays through the agent.
+With `request_approval`, the next DM from the stranger fires an approval card to the admin — admin taps Approve/Deny, approved users are added as members and their queued message replays through the agent.
 
 Non-interactive:
 
@@ -149,16 +147,10 @@ pnpm exec tsx .claude/skills/add-wechat/scripts/wire-dm.ts \
 Flags:
 
 - `--platform-id <id>` — wire a specific messaging group (default: most recent unwired)
-- `--agent-group <id>` — target agent group (default: prompt; auto-picked when only one exists)
-- `--sender-policy public|strict|request_approval` — override the messaging group's `unknown_sender_policy` (default: leave whatever the WeChat adapter declared when the row was auto-created)
+- `--agent-group <id>` — target agent group (default: prompt; or solo admin group in non-interactive)
+- `--sender-policy public|strict|request_approval` — default `request_approval` (fires an admin approval card on unknown-sender DMs)
 - `--session-mode shared|per-thread` — default `shared`
 
-Equivalent raw `ncl` invocation (host must be running):
-
-```bash
-ncl wirings create --messaging-group-id <mg-id> --agent-group-id <ag-id> --session-mode shared
-```
-
 ### 3. Test
 
 Have the sender message the bot again — the agent should respond.

.claude/skills/add-wechat/scripts/wire-dm.ts

@@ -5,49 +5,43 @@
  * After /add-wechat installs the adapter and the user scans the QR login,
  * the first inbound message from another WeChat account auto-creates a
  * `messaging_groups` row. This script finds that row, asks the operator
- * which agent group to wire it to, and creates the wiring via
- * `ncl wirings create` — engage mode/pattern and priority come from the
- * WeChat adapter's declared channel defaults, not from SQL baked into this
- * script, so it can't drift against schema migrations.
+ * which agent group to wire it to, and inserts the `messaging_group_agents`
+ * join row with sensible defaults — the "post-login wiring" step /add-wechat
+ * otherwise requires manual SQL for.
  *
- * PREREQUISITE: the NanoClaw host service must be RUNNING — `ncl` talks to
- * it over a Unix socket and has no offline mode.
- *
- * Usage (from the project root):
+ * Usage:
  *   pnpm exec tsx .claude/skills/add-wechat/scripts/wire-dm.ts
  *
  * Flags:
  *   --platform-id <id>      Wire a specific messaging group (default: most recent unwired)
- *   --agent-group <id>      Target agent group (default: interactive pick; auto-picked when only one exists)
- *   --sender-policy <p>     public | strict | request_approval — overrides the
- *                           channel-declared unknown_sender_policy on the
- *                           messaging group (default: leave as the adapter declared)
+ *   --agent-group <id>      Target agent group (default: interactive pick; or solo admin group)
+ *   --sender-policy <p>     public | strict (default: public)
  *   --session-mode <m>      shared | per-thread (default: shared)
  *   --non-interactive       Fail instead of prompting
  */
-import { spawnSync } from 'node:child_process';
+import Database from 'better-sqlite3';
 import path from 'node:path';
 import readline from 'node:readline';
-import { fileURLToPath } from 'node:url';
 
-// <root>/.claude/skills/add-wechat/scripts/wire-dm.ts → <root>
-const PROJECT_ROOT = path.resolve(path.dirname(fileURLToPath(import.meta.url)), '../../../..');
+const DB_PATH = process.env.NANOCLAW_DB_PATH ?? path.join(process.cwd(), 'data', 'v2.db');
 
 type SenderPolicy = 'public' | 'strict' | 'request_approval';
 
 interface Args {
   platformId?: string;
   agentGroupId?: string;
-  senderPolicy?: SenderPolicy;
+  senderPolicy: SenderPolicy;
   sessionMode: 'shared' | 'per-thread';
   interactive: boolean;
 }
 
 function parseArgs(argv: string[]): Args {
   const args: Args = {
-    // No --sender-policy default: the router already stamped the policy the
-    // WeChat adapter declares when it auto-created the messaging group.
-    // Only an explicit flag overrides it.
+    // Default matches the router's auto-create (`request_approval`) so the
+    // admin gets an approval card on the next unknown-sender DM rather than
+    // a silent allow. Pass `--sender-policy public` to open the channel to
+    // anyone, or `strict` to require explicit membership.
+    senderPolicy: 'request_approval',
     sessionMode: 'shared',
     interactive: true,
   };
@@ -74,90 +68,72 @@ function parseArgs(argv: string[]): Args {
   return args;
 }
 
-/** Run one ncl command against the running host and return its parsed data. */
-function ncl(...cliArgs: string[]): unknown {
-  const res = spawnSync('pnpm', ['exec', 'tsx', 'src/cli/client.ts', ...cliArgs, '--json'], {
-    cwd: PROJECT_ROOT,
-    encoding: 'utf-8',
-  });
-  if (res.error) throw res.error;
-  let frame: { ok: boolean; data?: unknown; error?: { message: string } } | undefined;
-  try {
-    frame = JSON.parse(res.stdout);
-  } catch {
-    // No frame — transport-level failure (host not running), reported on stderr.
-  }
-  if (frame && !frame.ok) throw new Error(`ncl ${cliArgs.join(' ')} failed: ${frame.error?.message}`);
-  if (!frame || res.status !== 0) {
-    const detail = (res.stderr || res.stdout || '').trim();
-    throw new Error(
-      `ncl ${cliArgs.join(' ')} failed:\n${detail}\n\n` +
-      'Is the NanoClaw host service running? ncl connects to it over a Unix socket.',
-    );
-  }
-  return frame.data;
-}
-
 async function prompt(q: string): Promise<string> {
   const rl = readline.createInterface({ input: process.stdin, output: process.stdout });
   return new Promise((resolve) => rl.question(q, (a) => { rl.close(); resolve(a.trim()); }));
 }
 
-interface MgRow { id: string; platform_id: string; name: string | null; is_group: number; created_at: string }
-interface AgRow { id: string; name: string; created_at: string }
+function generateId(prefix: string): string {
+  return `${prefix}-${Date.now()}-${Math.random().toString(36).slice(2, 8)}`;
+}
 
 async function main(): Promise<void> {
   const args = parseArgs(process.argv.slice(2));
-
-  const mgs = ncl('messaging-groups', 'list', '--channel-type', 'wechat') as MgRow[];
-  const wirings = ncl('wirings', 'list', '--limit', '10000') as Array<{ messaging_group_id: string }>;
-  const wiredMgIds = new Set(wirings.map((w) => w.messaging_group_id));
+  const db = new Database(DB_PATH);
+  db.pragma('journal_mode = WAL');
 
   // 1. Pick the messaging group
-  let mg: MgRow | undefined;
-  if (args.platformId) {
-    mg = mgs.find((r) => r.platform_id === args.platformId);
-    if (!mg) throw new Error(`no wechat messaging_group with platform_id = ${args.platformId}`);
-  } else {
-    const unwired = mgs
-      .filter((r) => !wiredMgIds.has(r.id))
-      .sort((a, b) => b.created_at.localeCompare(a.created_at));
+  let platformId = args.platformId;
+  if (!platformId) {
+    const rows = db.prepare(`
+      SELECT mg.id, mg.platform_id, mg.name, mg.is_group, mg.created_at
+      FROM messaging_groups mg
+      LEFT JOIN messaging_group_agents mga ON mga.messaging_group_id = mg.id
+      WHERE mg.channel_type = 'wechat' AND mga.id IS NULL
+      ORDER BY mg.created_at DESC
+    `).all() as Array<{ id: string; platform_id: string; name: string | null; is_group: number; created_at: string }>;
 
-    if (unwired.length === 0) {
+    if (rows.length === 0) {
       console.error('No unwired WeChat messaging groups found.');
       console.error('Send a message to the bot first (from another WeChat account), then re-run.');
       process.exit(1);
     }
 
-    if (unwired.length === 1 || !args.interactive) {
-      mg = unwired[0];
-      console.log(`Using most recent unwired group: ${mg.platform_id} (${mg.is_group ? 'group' : 'DM'})`);
+    if (rows.length === 1 || !args.interactive) {
+      platformId = rows[0].platform_id;
+      console.log(`Using most recent unwired group: ${platformId} (${rows[0].is_group ? 'group' : 'DM'})`);
     } else {
       console.log('Unwired WeChat messaging groups:');
-      unwired.forEach((r, i) => {
+      rows.forEach((r, i) => {
         console.log(`  ${i + 1}. ${r.platform_id}  (${r.is_group ? 'group' : 'DM'}, ${r.created_at})`);
       });
       const pick = await prompt('Pick one [1]: ');
       const idx = pick === '' ? 0 : parseInt(pick, 10) - 1;
-      if (Number.isNaN(idx) || idx < 0 || idx >= unwired.length) throw new Error('invalid choice');
-      mg = unwired[idx];
+      if (Number.isNaN(idx) || idx < 0 || idx >= rows.length) throw new Error('invalid choice');
+      platformId = rows[idx].platform_id;
     }
   }
 
+  const mg = db.prepare(
+    'SELECT id, platform_id, is_group FROM messaging_groups WHERE channel_type = ? AND platform_id = ?'
+  ).get('wechat', platformId) as { id: string; platform_id: string; is_group: number } | undefined;
+  if (!mg) throw new Error(`no wechat messaging_group with platform_id = ${platformId}`);
+
   // 2. Pick the agent group
   let agentGroupId = args.agentGroupId;
   if (!agentGroupId) {
-    const agents = (ncl('groups', 'list') as AgRow[])
-      .sort((a, b) => a.created_at.localeCompare(b.created_at));
+    const agents = db.prepare('SELECT id, name, is_admin FROM agent_groups ORDER BY is_admin DESC, created_at ASC')
+      .all() as Array<{ id: string; name: string; is_admin: number }>;
     if (agents.length === 0) throw new Error('no agent groups exist — create one first');
 
-    if (agents.length === 1) {
-      agentGroupId = agents[0].id;
-      console.log(`Auto-selected sole agent group: ${agents[0].name} (${agentGroupId})`);
+    const adminAgents = agents.filter((a) => a.is_admin === 1);
+    if (adminAgents.length === 1 && !args.interactive) {
+      agentGroupId = adminAgents[0].id;
+      console.log(`Auto-selected sole admin agent group: ${adminAgents[0].name} (${agentGroupId})`);
     } else if (args.interactive) {
       console.log('Agent groups:');
       agents.forEach((a, i) => {
-        console.log(`  ${i + 1}. ${a.name} (${a.id})`);
+        console.log(`  ${i + 1}. ${a.name} (${a.id})${a.is_admin ? ' [admin]' : ''}`);
       });
       const pick = await prompt('Pick one [1]: ');
       const idx = pick === '' ? 0 : parseInt(pick, 10) - 1;
@@ -168,29 +144,26 @@ async function main(): Promise<void> {
     }
   }
 
-  const ag = (ncl('groups', 'list') as AgRow[]).find((a) => a.id === agentGroupId);
+  const ag = db.prepare('SELECT id, name FROM agent_groups WHERE id = ?').get(agentGroupId) as
+    { id: string; name: string } | undefined;
   if (!ag) throw new Error(`no agent_group with id = ${agentGroupId}`);
 
-  // 3. Wire, then apply the optional policy override. Engage mode/pattern and
-  //    priority are filled by the wirings resolveDefaults hook from the WeChat
-  //    adapter's declared channel defaults. Policy update runs second so a
-  //    failed create (e.g. already wired) leaves the mg row untouched.
-  const wiring = ncl(
-    'wirings', 'create',
-    '--messaging-group-id', mg.id,
-    '--agent-group-id', ag.id,
-    '--session-mode', args.sessionMode,
-  ) as { engage_mode: string; engage_pattern: string | null };
-  if (args.senderPolicy) {
-    ncl('messaging-groups', 'update', mg.id, '--unknown-sender-policy', args.senderPolicy);
-  }
+  // 3. Update sender policy + wire
+  const tx = db.transaction(() => {
+    db.prepare('UPDATE messaging_groups SET unknown_sender_policy = ? WHERE id = ?')
+      .run(args.senderPolicy, mg.id);
+
+    db.prepare(`
+      INSERT INTO messaging_group_agents
+        (id, messaging_group_id, agent_group_id, trigger_rules, response_scope, session_mode, priority, created_at)
+      VALUES (?, ?, ?, '', 'all', ?, 10, datetime('now'))
+    `).run(generateId('mga'), mg.id, ag.id, args.sessionMode);
+  });
+  tx();
 
   console.log('');
-  console.log(
-    `WIRED platform_id=${mg.platform_id} agent_group=${ag.name} ` +
-    `engage=${wiring.engage_mode}${wiring.engage_pattern ? `(${wiring.engage_pattern})` : ''} ` +
-    `policy=${args.senderPolicy ?? '(channel default)'} mode=${args.sessionMode}`,
-  );
+  console.log(`WIRED platform_id=${mg.platform_id} agent_group=${ag.name} policy=${args.senderPolicy} mode=${args.sessionMode}`);
+  db.close();
 }
 
 main().catch((err) => {

.claude/skills/add-whatsapp/SKILL.md

@@ -20,7 +20,6 @@ Skip to **Credentials** if all of these are already in place:
 - `src/channels/whatsapp.test.ts` exists
 - `src/channels/index.ts` contains `import './whatsapp.js';`
 - `setup/whatsapp-auth.ts` and `setup/groups.ts` both exist
-- `container/skills/whatsapp-formatting/instructions.md` exists
 - `setup/index.ts`'s `STEPS` map contains both `'whatsapp-auth':` and `groups:`
 - `@whiskeysockets/baileys`, `qrcode`, `pino` are listed in `package.json` dependencies
 - `.claude/skills/add-whatsapp/scripts/wa-qr-browser.ts` exists (ships with this skill)
@@ -41,17 +40,8 @@ git show origin/channels:src/channels/whatsapp-registration.test.ts    > src/cha
 git show origin/channels:src/channels/whatsapp.test.ts                 > src/channels/whatsapp.test.ts
 git show origin/channels:setup/whatsapp-auth.ts                        > setup/whatsapp-auth.ts
 git show origin/channels:setup/groups.ts                               > setup/groups.ts
-mkdir -p container/skills/whatsapp-formatting
-git show origin/channels:container/skills/whatsapp-formatting/SKILL.md        > container/skills/whatsapp-formatting/SKILL.md
-git show origin/channels:container/skills/whatsapp-formatting/instructions.md > container/skills/whatsapp-formatting/instructions.md
 ```
 
-The `whatsapp-formatting` container skill is part of the channel payload: its
-`instructions.md` becomes the `skill-whatsapp-formatting.md` fragment in every
-group's composed CLAUDE.md (see `src/claude-md-compose.ts`), teaching agents
-WhatsApp's formatting syntax. Trunk does not ship it — without this copy step
-agents format WhatsApp messages with generic markdown that renders literally.
-
 ### 3. Append the self-registration import
 
 Append to `src/channels/index.ts` (skip if already present):
@@ -92,7 +82,7 @@ WhatsApp uses linked-device authentication — no API key, just a one-time pairi
 
 ### Check current state
 
-Check if WhatsApp is already authenticated. If `store/auth/creds.json` exists, skip to "Dedicated vs personal number".
+Check if WhatsApp is already authenticated. If `store/auth/creds.json` exists, skip to "Shared vs dedicated number".
 
 ```bash
 test -f store/auth/creds.json && echo "WhatsApp auth exists" || echo "No WhatsApp auth"
@@ -202,60 +192,16 @@ for i in $(seq 1 60); do grep -q 'STATUS: authenticated' /tmp/wa-auth.log 2>/dev
 test -f store/auth/creds.json && echo "Authentication successful" || echo "Authentication failed"
 ```
 
-## Dedicated vs personal number
-
-The adapter behaves fundamentally differently depending on whether the linked number is the assistant's own or the operator's personal one. The switch is `ASSISTANT_HAS_OWN_NUMBER` in `.env`, read by the adapter itself at startup. **Inference rule: absent (or anything other than `true`) means shared/personal** — the safe default, since misreading a personal number as dedicated makes the bot claim messages addressed to the human.
-
-- **Shared/personal number** (`ASSISTANT_HAS_OWN_NUMBER` unset or not `true`) — DMs to this number and group @-tags of it address the *human*, not the bot. The adapter never emits a mention signal (`mentions: 'never'` in its declared channel defaults), so: no stranger DM ever auto-creates a messaging group or raises an admin approval card; group wirings default to a name pattern (`\b<AgentName>\b`) instead of platform mentions; auto-created chats default to `unknown_sender_policy: 'strict'`; outbound messages are prefixed with the assistant's name.
-- **Dedicated number** (`ASSISTANT_HAS_OWN_NUMBER=true`) — everything sent to the number is for the bot. DMs and group mentions carry a real mention signal (`mentions: 'platform'`), unknown senders escalate via `request_approval` approval cards, and card-approved groups wire with `engage_mode: 'mention'`. No name prefix on outbound.
+### Shared vs dedicated number
 
 AskUserQuestion: Is this a shared phone number (personal WhatsApp) or a dedicated number?
 - **Shared number** — your personal WhatsApp (bot prefixes messages with its name)
 - **Dedicated number** — a separate phone/SIM for the assistant
 
-Write the answer to `.env` **explicitly in both cases** (don't rely on the inference rule for new installs):
+If dedicated, add to `.env`:
 
 ```bash
-# Dedicated:
 ASSISTANT_HAS_OWN_NUMBER=true
-# Shared/personal:
-ASSISTANT_HAS_OWN_NUMBER=false
-```
-
-### Update path: existing install, flag unset
-
-If WhatsApp auth already exists (`store/auth/creds.json` present) but `.env` has no `ASSISTANT_HAS_OWN_NUMBER` line, the install predates the explicit switch. Ask the operator which mode applies and write it explicitly.
-
-Suggest a default by comparing the authed number against the wired DM chat:
-
-```bash
-# The number this install is authenticated as
-node -e "const c=JSON.parse(require('fs').readFileSync('store/auth/creds.json','utf-8'));console.log(c.me?.id?.split(':')[0])"
-# The wired WhatsApp DM chats
-pnpm exec tsx scripts/q.ts data/v2.db "SELECT mg.platform_id FROM messaging_groups mg JOIN messaging_group_agents mga ON mg.id=mga.messaging_group_id WHERE mg.channel_type='whatsapp' AND mg.is_group=0"
-```
-
-If the wired DM's phone **equals** the authed number, the operator is talking to the bot in their own self-chat — that's a personal number: suggest **Shared**. If they differ, the operator messages the bot from a different number: suggest **Dedicated**. Confirm with the operator either way, then write the flag and restart the service.
-
-### Migration audit: spam-era group wirings
-
-Before the shared-number fix, group chats approved via the channel-registration card were wired `engage_mode='pattern'` with pattern `.` — respond-to-everything — because the card flow couldn't tell groups from DMs on non-threaded platforms. On a personal number this shows up as the bot answering every message in family/work groups after someone once tapped Connect on a spam-triggered card.
-
-List the suspect wirings (host service running — `ncl` is socket-only):
-
-```bash
-ncl wirings list --engage-mode pattern --engage-pattern "." --json
-```
-
-Cross-reference against WhatsApp group chats (`ncl messaging-groups list --channel-type whatsapp --is-group 1`). For each wiring with pattern `.` on a WhatsApp group that is *not* the operator's deliberate always-on chat (e.g. their self-chat), offer:
-
-- **Flip to name-based engagement**: `ncl wirings update <wiring-id> --engage-mode pattern --engage-pattern '\b<AgentName>\b'` (or `--engage-mode mention` on a dedicated number)
-- **Delete the wiring**: `ncl wirings delete <wiring-id>`
-
-Stale approval cards from that era can also linger. Clear pending channel approvals for chats the operator doesn't want wired:
-
-```bash
-pnpm exec tsx scripts/q.ts data/v2.db "DELETE FROM pending_channel_approvals WHERE messaging_group_id IN (SELECT id FROM messaging_groups WHERE channel_type='whatsapp')"
 ```
 
 ## Next Steps
@@ -333,12 +279,3 @@ systemctl --user start $(systemd_unit)
 ### "conflict" disconnection
 
 Two instances connected with same credentials. Ensure only one NanoClaw process is running.
-
-### Trunk updated but shared-number behavior unchanged (stale adapter copy)
-
-The shared-number behavior (no stranger approval cards, name-pattern group defaults) lives in the **adapter copy** at `src/channels/whatsapp.ts`, installed from the `channels` branch — not in trunk. If you updated trunk via `/update-nanoclaw` but skipped the skill-update step, the old adapter copy neither reads `ASSISTANT_HAS_OWN_NUMBER` itself nor declares channel defaults, so trunk falls back to the legacy behavior: approval cards still fire on a personal number, and new wirings get the channel-blind defaults. Symptoms of the skew:
-
-- `.env` says `ASSISTANT_HAS_OWN_NUMBER=false` (or unset) but strangers' DMs still raise approval cards
-- `ncl wirings create` on a WhatsApp group defaults to `mention` instead of a name pattern
-
-Fix: re-run `/add-whatsapp` (or `/update-skills`) to pull the current adapter from the `channels` branch, then restart the service. The reverse skew (new adapter, old trunk) can't happen — the adapter's `defaults` field is optional and old trunk ignores it.

.claude/skills/init-first-agent/SKILL.md

@@ -113,7 +113,7 @@ If they say it didn't arrive, then diagnose using the DB directly (no waiting lo
 
 **"Missing required args"** — the script wants `--channel`, `--user-id`, `--platform-id`, `--display-name` at minimum. Re-check the command you assembled.
 
-**No `messaging_groups` row appears after the user DMs (step 3a)** — auto-created rows are stamped with the channel adapter's declared `unknown_sender_policy` (two-level model: adapter declaration → per-row override; `strict` only when the adapter has no declaration). Under `strict` the router silently drops messages from unknown senders but still creates the `messaging_groups` row; under `request_approval` an approval card goes to an admin instead. If the row is missing entirely, the adapter isn't receiving the inbound message. Check `logs/nanoclaw.log` for adapter errors (auth, gateway disconnect, rate limit).
+**No `messaging_groups` row appears after the user DMs (step 3a)** — the router silently drops messages from unknown senders under `strict` policy but still creates the `messaging_groups` row. If the row is missing entirely, the adapter isn't receiving the inbound message. Check `logs/nanoclaw.log` for adapter errors (auth, gateway disconnect, rate limit).
 
 **Owner already exists** — `hasAnyOwner()` returned true, so the grant is skipped silently. That's fine; the script still creates the agent and wiring. Reassigning ownership needs a separate flow (not this skill).
 

.claude/skills/manage-channels/SKILL.md

@@ -22,7 +22,7 @@ pnpm exec tsx scripts/q.ts data/v2.db "<query>"
 ```sql
 SELECT id, name AS assistant_name, folder, agent_provider FROM agent_groups;
 SELECT id, channel_type, platform_id, name, unknown_sender_policy FROM messaging_groups;
-SELECT messaging_group_id, agent_group_id, engage_mode, engage_pattern, session_mode, threads, priority FROM messaging_group_agents;
+SELECT messaging_group_id, agent_group_id, session_mode, priority FROM messaging_group_agents;
 SELECT user_id, role, agent_group_id FROM user_roles ORDER BY role='owner' DESC;
 ```
 
@@ -36,47 +36,6 @@ If the instance has no owner yet (`SELECT COUNT(*) FROM user_roles WHERE role='o
 
 **Delegate to `/init-first-agent`.** It handles: channel choice, operator identity lookup, DM platform id resolution (with cold-DM or pair-code fallback), agent group creation, wiring, and the welcome DM. Return here afterward for any additional channels.
 
-## Channel Defaults: The Two-Level Model
-
-Wiring defaults (engage mode/pattern, threading, `unknown_sender_policy`) resolve through **exactly two levels**:
-
-1. **Adapter declaration** — each channel adapter declares `ChannelDefaults` (separate DM and group contexts, plus a `mentions` capability) in its source file. The adapter copy is skill-installed and user-owned: to change a default install-wide, edit `src/channels/<channel>.ts` and restart. Declarations are never persisted to the DB.
-2. **Per-wiring/per-mg values chosen at creation** — every creation surface (`ncl wirings create` / `ncl messaging-groups create`, the `register` wizard step, the approval-card flow, `/init-first-agent`) fills omitted fields from the declaration and stores the result on the row. Pass explicit flags to override one wiring.
-
-There is no third level: existing rows are never re-resolved, so editing a declaration only affects wirings created afterward. The one exception is the **`threads` column**, which stays live — `NULL` means "inherit the declaration at message time".
-
-Channels with no declaration (stale adapter copies) fall back to the legacy behavior; run `/update-skills` to pull current adapters.
-
-### Wiring via ncl
-
-`ncl` requires the **host service to be running** (it connects over a Unix socket):
-
-```bash
-ncl messaging-groups create --channel-type <type> --platform-id "<id>" --name "<name>" [--is-group 1]
-ncl wirings create --messaging-group-id <mg-id> --agent-group-id <ag-id> [--session-mode <mode>]
-```
-
-Omitted `engage_mode`/`engage_pattern`/`unknown_sender_policy` come from the adapter declaration for the right context (DM vs group). Run `ncl wirings help` / `ncl messaging-groups help` for the full flag list.
-
-### Threading override (`--threads`)
-
-`ncl wirings create/update ... --threads true|false` controls whether platform thread ids are honored for this wiring. `true` (in groups) means per-thread sessions and in-thread replies/typing/cards; `false` collapses to a flat session with top-level replies. Omitted = `NULL` = inherit the channel declaration. A wiring can *disable* threads on a threaded platform (Slack, Discord, GitHub), never enable them on a non-threaded one.
-
-Two consequences to warn the user about:
-
-- **Session identity**: sessions are never deleted. Flipping `threads` on a live wiring orphans existing per-thread sessions (or splinters a shared one) — history stays in the old sessions; new messages start fresh ones.
-- **`mention-sticky` needs threads**: sticky engagement is keyed on per-thread session existence, so with resolved threads off it would engage once and never disengage. Creation and update coerce `mention-sticky` → `mention` (with a warning) when the effective thread policy is off.
-
-### Mention capability
-
-Each declaration states which mention signal the adapter emits: `platform` (real platform mentions), `dm-only` (only DMs are flagged), or `never`. On a `mentions: 'never'` channel (Linear OAuth apps, WhatsApp personal-number mode, Emacs), `mention`/`mention-sticky` wirings are **inert — they can never engage** — and `ncl` rejects them at create/update with an error citing the declaration. For groups on those channels, use a name pattern instead:
-
-```bash
-ncl wirings update <id> --engage-mode pattern --engage-pattern '(?i)^@?<Name>\b'
-```
-
-**Renaming an agent group does not update stored patterns.** Declared group patterns containing `{name}` are substituted with the agent group's name *at creation* and stored literally — after `ncl groups update <id> --name <NewName>`, audit that group's wirings for patterns still matching the old name and update them.
-
 ## Wire New Channel
 
 For each unwired channel:
@@ -108,8 +67,6 @@ pnpm exec tsx setup/index.ts --step register -- \
 
 The `register` step creates the agent group (reusing it if the folder already exists), the messaging group, and the wiring row. `createMessagingGroupAgent` auto-creates the companion `agent_destinations` row so the agent can address the channel by name.
 
-Omitted engage/policy fields default from the channel adapter's declaration (see "Channel Defaults" above). Optional overrides: `--trigger "<regex>"` (explicit engage pattern), `--engage-mode <pattern|mention|mention-sticky>`, `--is-group <true|false>`, `--unknown-sender-policy <strict|request_approval|public>`. Don't pick a mention mode on a channel whose declaration says `mentions: 'never'` — it can never engage there.
-
 When creating a NEW agent group on a non-default provider, append `--provider <name>` (e.g. `--provider codex`) — there is no install-wide default; existing groups switch via `ncl groups config update --provider` instead.
 
 For separate agents, also ask for a folder name and optionally a different assistant name.
@@ -118,7 +75,7 @@ For separate agents, also ask for a folder name and optionally a different assis
 
 When adding another group/chat on an already-configured platform (e.g. a second Telegram group):
 
-1. **Telegram:** ask the isolation question first to determine intent (`wire-to:<folder>` for an existing agent, `new-agent:<folder>` for a fresh one). Run `pnpm exec tsx setup/index.ts --step pair-telegram -- --intent <intent>`, show the `CODE` from the `PAIR_TELEGRAM_CODE` status block, and tell the user to post `@<botname> CODE` in the target group (or DM the bot for a private chat). Wait for the final `PAIR_TELEGRAM` block. The inbound interceptor has already created the `messaging_groups` row stamped with the Telegram adapter's declared policy (`request_approval` on current adapter copies; `strict` only on stale pre-declaration copies) and upserted the paired user — `register` only needs to add the wiring:
+1. **Telegram:** ask the isolation question first to determine intent (`wire-to:<folder>` for an existing agent, `new-agent:<folder>` for a fresh one). Run `pnpm exec tsx setup/index.ts --step pair-telegram -- --intent <intent>`, show the `CODE` from the `PAIR_TELEGRAM_CODE` status block, and tell the user to post `@<botname> CODE` in the target group (or DM the bot for a private chat). Wait for the final `PAIR_TELEGRAM` block. The inbound interceptor has already created the `messaging_groups` row with `unknown_sender_policy = 'strict'` and upserted the paired user — `register` only needs to add the wiring:
 
    ```bash
    pnpm exec tsx setup/index.ts --step register -- \
@@ -137,16 +94,6 @@ When adding another group/chat on an already-configured platform (e.g. a second
 3. Delete the old `messaging_group_agents` entry, create a new one
 4. Note: existing sessions stay with the old agent group; new messages route to the new one. The `agent_destinations` row created for the old wiring is NOT automatically removed — if you want the old agent to stop seeing the channel as a named target, delete it from `agent_destinations` manually.
 
-## One-Time Check: Legacy Mis-Wired WhatsApp Groups
-
-Installs that approved WhatsApp group registration cards before the channel-defaults model wired those groups as `engage_mode='pattern'`, `engage_pattern='.'` — respond-to-everything (the card flow couldn't tell groups from DMs on non-threaded platforms). Check once:
-
-```bash
-pnpm exec tsx scripts/q.ts data/v2.db "SELECT mga.id, mg.platform_id, mg.name FROM messaging_group_agents mga JOIN messaging_groups mg ON mg.id = mga.messaging_group_id WHERE mg.channel_type='whatsapp' AND mg.is_group=1 AND mga.engage_mode='pattern' AND mga.engage_pattern='.'"
-```
-
-For any hit the operator didn't deliberately configure as always-on, offer the repair options in `/add-whatsapp`'s "Migration audit" section (flip to mention/name-pattern engagement, or delete the wiring).
-
 ## Show Configuration
 
 Display a readable summary showing:

.claude/skills/migrate-from-openclaw/SKILL.md

@@ -194,10 +194,8 @@ Notes:
   runtime, so pass the `=>` value discovery emitted (or the raw OpenClaw id).
 - Reuse a `--folder` to put a group on an existing agent (shared base/separate
   conversations); use a new `--folder` for a fully separate agent.
-- Engage defaults come from the channel adapter's declaration (most group
-  chats default to mention-based engagement; channels without a mention
-  signal default to a name pattern). Pass `--trigger` to set an explicit
-  regex, or `--no-trigger-required` for respond-to-everything.
+- Group chats default to mention-only; pass `--trigger` to set a regex, or
+  `--no-trigger-required` for respond-to-everything.
 - Register groups from channels v2 doesn't support yet too — the messaging
   group and wiring persist and activate when that channel is installed.
 
@@ -240,13 +238,10 @@ model, which is **not** a JSON file. Each messaging group has an
 - `dmPolicy: "disabled"` → don't wire that chat (or leave it registered but
   unwired).
 
-The messaging groups `register` / `init-first-agent` create default their
-`unknown_sender_policy` to whatever the channel adapter declares for that
-context (DM vs group) — `strict` when the channel has no declaration — so
-unknown senders are gated until you add them (or an admin approves the
-adapter-declared approval card). Pass `--unknown-sender-policy` to `register`
-to override. Show the user the OpenClaw allowlist and confirm who to grant
-before running the commands.
+The messaging groups `register` / `init-first-agent` create already default to
+`unknown_sender_policy = 'strict'`, so unknown senders are gated until you add
+them. Show the user the OpenClaw allowlist and confirm who to grant before
+running the commands.
 
 ## Phase 3: Identity and Memory
 

.claude/skills/update-nanoclaw/SKILL.md

@@ -281,34 +281,6 @@ Keep it to these two options — the per-skill selection lives inside
   its Step 4 — so nothing container-related is owed back here.)
 - On "Skip": note that `/update-skills` can be run anytime, then proceed.
 
-## Known behavior changes when channel adapters update
-
-Channel adapters now declare per-channel wiring defaults (engage mode, threading,
-sender policy). Updating trunk alone changes nothing for existing rows, but once
-`/update-skills` pulls current adapter copies, two deliberate behavior changes
-land. If the user's install has Slack, Discord, or WhatsApp, tell them:
-
-1. **Slack/Discord DM replies move top-level.** Both adapters now declare
-   `threads: false` for DMs, so DM replies stop chasing per-message sub-threads
-   and land in the main DM view, matching the DM session (which was already
-   flat). Group/channel threading is unchanged. To keep the old in-thread DM
-   behavior for a specific wiring, override it per wiring:
-   `ncl wirings update <wiring-id> --threads true`.
-2. **Shared-identity channels stop raising stranger approval cards.** On
-   channels where the linked account is the operator's personal identity, the
-   mechanics differ by channel: WhatsApp personal-number mode suppresses the
-   mention signal entirely (no auto-created messaging groups, no cards);
-   iMessage and WeChat still emit DM mention signals — stranger DMs still
-   auto-create `messaging_groups` rows — but their declared `strict` policy
-   makes those rows drop unknown senders silently instead of raising
-   channel-registration cards to the admin.
-
-**WhatsApp installs on a shared/personal number should re-run `/add-whatsapp`**
-after the skill update: it now asks the dedicated-vs-personal question
-explicitly (writing `ASSISTANT_HAS_OWN_NUMBER` to `.env`), audits for legacy
-mis-wired group rows from spam-era approval cards, and shows how to clear
-stale pending approvals.
-
 Proceed to Step 7.9.
 
 # Step 7.9: Stamp the upgrade marker (required)

.github/workflows/label-pr.yml

@@ -14,7 +14,6 @@ jobs:
     runs-on: ubuntu-latest
     permissions:
       pull-requests: write
-      issues: write # createLabel — auto-provisions the core-team label
     steps:
       - uses: actions/github-script@v7
         with:
@@ -31,24 +30,6 @@ jobs:
 
             if (body.includes('contributing-guide: v1')) labels.push('follows-guidelines');
 
-            // Lowercase GitHub logins; keep in sync with the core team roster.
-            const CORE_TEAM = ['gavrielc', 'koshkoshinsk', 'glifocat', 'gabi-simons', 'omri-maya', 'amit-shafnir', 'moshe-nanoco'];
-            const author = context.payload.pull_request.user.login.toLowerCase();
-            if (CORE_TEAM.includes(author)) {
-              labels.push('core-team');
-              try {
-                await github.rest.issues.createLabel({
-                  owner: context.repo.owner,
-                  repo: context.repo.repo,
-                  name: 'core-team',
-                  color: '1D76DB',
-                  description: 'PR opened by a core team member',
-                });
-              } catch (e) {
-                if (e.status !== 422) throw e; // 422: label already exists
-              }
-            }
-
             if (labels.length > 0) {
               await github.rest.issues.addLabels({
                 owner: context.repo.owner,

CHANGELOG.md

@@ -4,12 +4,7 @@ All notable changes to NanoClaw will be documented in this file.
 
 ## [Unreleased]
 
-- **New skill: `/add-audit` — opt-in local audit log for the `ncl` surface.** Installs an append-only, SIEM-shaped audit log: every command through the dispatcher (both transports — host socket and container — including scope denials, approval holds, and approved replays) becomes one canonical NDJSON event under `data/audit/<UTC-day>.ndjson`. Gated chains share a `correlation_id` (the approval id: the hold's `pending` event and the replay's terminal event carry the same one); `details` pass a recursive secret-key redactor (~2 KB value cap). `AUDIT_RETENTION_DAYS` (default 90; `0` = keep forever) hard-deletes day-files past the horizon at boot and once per UTC day. Read back with `ncl audit list [--actor --action --resource --outcome --since --until --correlation --limit] [--format ndjson]` — host + global-scope callers only (the resource stays off the group-scope allowlist, so group-scoped agents fail closed). In-process exporters plug in via `registerAuditHook` — post-write hooks that fire only after the local append succeeds. Off by default: nothing is persisted (and `data/audit/` is never created) until `AUDIT_ENABLED=true`, an enabled box refuses to boot if the directory isn't writable, and a disabled box answers `ncl audit list` with a clear error instead of an empty list. The skill's whole core footprint is the dispatch composition (`export const dispatch = withAudit(dispatchInner)`) plus the resource-barrel import, both guarded by a shipped wiring test. Approval-lifecycle events (request/decision as their own events), OneCLI credential holds, and channel/sender events are later increments on the same schema.
-- **The guard seam.** Every privileged action crossing the container or channel boundary now passes ONE decision function — `guard()` in the new `src/guard/` leaf — before it executes: `allow`, `hold` (through the flow's existing approval mechanics), or `deny`. The keyed registries (ncl commands, delivery actions) wrap their handlers at registration, so the guarded path is the only path by construction: every ncl command derives its guard from its own definition inside `register()`, and a delivery action registers with a guard spec or an explicit `unguarded(<reason>)` declaration — omission doesn't compile, and `grep "unguarded("` is the complete justified inventory. The broadcast hooks (response handlers, message interceptors) stay plain registrations; the one privileged click path — channel registration — consults the guard inline in its handler, like the a2a route and the unknown-sender gate. Consults carry the branded `GuardedAction` value returned by `defineGuardedAction`, so a typo'd or dropped wiring is a compile error and a forged value is denied at runtime — never a fail-open. The decision is today's checks verbatim (cli_scope enforcement, create_agent's scope branch, a2a destination ACL + `agent_message_policies` hold, self-mod unconditional hold, unknown_sender_policy, channel-registration click auth, host-as-trusted-caller in code). Policy-as-data (tighten-only rule sources composing with the decision) is deliberately deferred — a generalized rules table can arrive later, with its first operator-visible consumer. Approved replays now carry the verified approval row as a **grant** — the `approved: true` boolean is deleted — and the guard re-runs the structural checks on every replay. Two outcome changes are inherent to that replay semantics and ship deliberately: **(a)** approving a held a2a message after its destination was revoked no longer delivers it (the checks re-run live); **(b)** a forged, already-consumed, or wrong-action/wrong-payload grant refuses the replay instead of executing (previously any in-process caller passing `approved: true` executed). Zero rules ship by default — the seeded posture is today's behavior. (The D1/D2/D4 click-auth fixes from the guarded-actions defect inventory are NOT in this change — they belong to the approval-contract PR.)
-- **Delivery-registry hardening.** Re-registering a guard-wrapped delivery action *without* a guard spec now throws at registration — previously that silently replaced the guarded handler while the catalog still reported the action as guarded. (The cross-registry pairing — every holding action has a registered approve continuation — is enforced by the conformance test; at runtime a missing continuation already resolves loudly, telling the requester no handler is installed.)
-- [BREAKING] **`whatsapp-formatting` and `slack-formatting` container skills moved from trunk to the `channels` branch.** They now install with their channel — `/add-whatsapp` / `/add-slack` and the setup installers copy them in — so installs without those channels stop carrying channel-specific formatting instructions in every agent's context. **Migration — only if this install has the channel wired** (check `src/channels/whatsapp.ts` / `src/channels/slack.ts`): updating removes both skills from the working tree — WhatsApp agents lose the formatting fragment from their composed CLAUDE.md on next spawn, Slack agents lose the mrkdwn skill from `~/.claude/skills`. Re-run the matching skill, `/add-whatsapp` or `/add-slack` (idempotent), to restore. Installs without the channel need nothing — do NOT run the add-skill just in case; it installs the full channel adapter.
-- **Pre-task script failures back their series off instead of spinning.** A `--script` that errors lands the occurrence as a failed run (`script-skip:error` ack → `failed` status); recurrence reads the series' trailing failed streak and re-arms at `max(cron next, now + 2·2^(n−1) min, cap 60)`; after 8 consecutive failures the series is auto-paused with a host-written note in its run log (`ncl tasks resume` revives it). A deliberate `wakeAgent:false` gate is a normal run and never backs off. Also fixed: an explicitly-addressed `<message to>` in a task fire's final text now delivers as a deliberate send (previously suppressed as a turn-reply echo → zero delivery when the agent skipped the MCP tool); identical echoes of an MCP send are dropped in the runner, where the duplication originates.
-- [BREAKING] **Scheduled tasks moved from MCP tools to `ncl tasks`.** The six scheduling MCP tools are no longer exposed to agent containers; agents and operators manage tasks with `ncl tasks list/get/create/update/cancel/pause/resume/delete`. New tasks run from a per-agent-group system session rather than waking the chat session that created them, and task writes are not approval-gated inside the owning group. **Migration:** [docs/ncl-tasks-migration.md](docs/ncl-tasks-migration.md).
+- **Opt-in local audit log.** `AUDIT_ENABLED=true` records every `ncl` command (both transports, including scope denials) and every host-routed approval — request, decision, and terminal outcome, covering CLI gates, self-mod, a2a message gates, agent creation (incl. the ungated global-scope door and the channel-registration name flow), the permissions sender/channel cards, and OneCLI credential holds — as one canonical SIEM-shaped event per action, appended to NDJSON day-files under `data/audit/`. Gated chains share a `correlation_id` (the approval id); details pass a recursive secret-key redactor and message-bearing events record shape only (never bodies). `AUDIT_RETENTION_DAYS` (default 90; `0` = keep forever) hard-deletes day-files past the horizon at boot + once daily in the host sweep. Read back with `ncl audit list [--actor --action --resource --outcome --since --until --correlation --limit] [--format ndjson]` — host + global-scope callers only. In-process consumers (future exporters) plug in via `registerAuditHook` — post-write hooks with an init/maintain/shutdown lifecycle that fire only after the local append succeeds, so external systems can never be ahead of the source of truth; no forwarder, credentials, or transport ships in core. Off by default: nothing is persisted until enabled, and an enabled box refuses to boot if `data/audit/` isn't writable. See [docs/SECURITY.md](docs/SECURITY.md#6-local-audit-log-opt-in).
 - **Optional per-container resource caps.** `CONTAINER_CPU_LIMIT` and `CONTAINER_MEMORY_LIMIT` pass through to `docker run` as `--cpus` / `--memory` (`container-runner.ts`). Both empty by default — no flag added, spawn args byte-identical to today — so existing installs are unaffected. Set them to cap an agent container's CPU/memory so one agent can't monopolize the host (e.g. `CONTAINER_CPU_LIMIT=2`, `CONTAINER_MEMORY_LIMIT=8g`). Swap is intentionally not managed here: `--memory` is a hard cap on a swapless host.
 - [BREAKING] **Chat SDK pinned to `4.29.0` (was `4.26.0` via `^4.24.0`).** `chat` and the `@chat-adapter/*` channel adapters are version-locked — the adapter's `ChatInstance` must match the bridge's, so a mismatched pair fails to typecheck at `createChatSdkBridge(...)`. `chat` is therefore pinned exactly, and the channel-adapter install pins move with it — the `/add-<channel>` SKILL.md steps and `setup/*.sh` scripts on `main`, plus the adapter code on the `channels` branch. Core installs with no channel (only `cli`) are unaffected. **Migration:** if any channel is installed (Slack, Discord, Telegram, Teams, …), re-run its `/add-<channel>` skill to pull the matching `4.29.0` adapter.
 - **Budget/billing-exhausted LLM turns now reach the user instead of being silently dropped.** When a turn ends in a non-retryable provider error (e.g. an Anthropic `403 billing_error`) with no `<message>` wrapping, the agent-runner delivers the provider's notice to the originating channel and stops re-nudging the failing gateway. `providers/claude.ts` now surfaces the SDK's `is_error` flag (and the error subtype's `errors[]` text); `poll-loop.ts` delivers that text and skips the re-wrap retry. Fixes the case where a spend-limit notice produced silence plus a turn-after-turn retry loop.

CLAUDE.md

@@ -15,11 +15,11 @@ If you are a fresh install (you ran `git clone`, not `git pull`) and there are n
 
 # NanoClaw
 
-Personal AI assistant. See [README.md](README.md) for philosophy and setup. Architecture lives in `docs/`.
+Personal Claude assistant. See [README.md](README.md) for philosophy and setup. Architecture lives in `docs/`.
 
 ## Quick Context
 
-The host is a single Node process that orchestrates per-session agent containers. Platform messages land via channel adapters, route through an entity model (users → messaging groups → agent groups → sessions), get written into the session's inbound DB, and wake a container. The agent-runner inside the container polls the DB, calls the agent, and writes back to the outbound DB. The host polls the outbound DB and delivers through the same adapter.
+The host is a single Node process that orchestrates per-session agent containers. Platform messages land via channel adapters, route through an entity model (users → messaging groups → agent groups → sessions), get written into the session's inbound DB, and wake a container. The agent-runner inside the container polls the DB, calls Claude, and writes back to the outbound DB. The host polls the outbound DB and delivers through the same adapter.
 
 **Everything is a message.** There is no IPC, no file watcher, no stdin piping between host and container. The two session DBs are the sole IO surface.
 
@@ -32,7 +32,7 @@ agent_group_members (user_id, agent_group_id)    — unprivileged access gate
 user_dms (user_id, channel_type, messaging_group_id) — cold-DM cache
 
 agent_groups (workspace, memory, CLAUDE.md, personality, container config)
-    ↕ many-to-many via messaging_group_agents (session_mode, engage_mode/engage_pattern, sender_scope, priority)
+    ↕ many-to-many via messaging_group_agents (session_mode, trigger_rules, priority)
 messaging_groups (one chat/channel on one platform; instance = adapter-instance name, defaults to channel_type; unknown_sender_policy)
 
 sessions (agent_group_id + messaging_group_id + thread_id → per-session container)
@@ -44,8 +44,8 @@ Privilege is user-level (owner/admin), not agent-group-level. See [docs/isolatio
 
 Each session has **two** SQLite files under `data/v2-sessions/<session_id>/`:
 
-- `inbound.db` — host writes, container reads. `messages_in`, delivered, destinations, session_routing.
-- `outbound.db` — container writes, host reads. `messages_out`, processing_ack, session_state, container_state.
+- `inbound.db` — host writes, container reads. `messages_in`, routing, destinations, pending_questions, processing_ack.
+- `outbound.db` — container writes, host reads. `messages_out`, session_state.
 
 Exactly one writer per file — no cross-mount lock contention. Heartbeat is a file touch at `/workspace/.heartbeat`, not a DB update. Host uses even `seq` numbers, container uses odd.
 
@@ -62,27 +62,25 @@ For ad-hoc queries from skills or scripts, use the in-tree wrapper rather than t
 | `src/index.ts` | Entry point: init DB, migrations, channel adapters, delivery polls, sweep, shutdown |
 | `src/router.ts` | Inbound routing: messaging group → agent group → session → `inbound.db` → wake |
 | `src/delivery.ts` | Polls `outbound.db`, delivers via adapter, handles system actions (schedule, approvals, etc.) |
-| `src/delivery-guard.ts` | `DeliveryGuardSpec` + `runGuarded` — the precheck → guard → deny/hold/allow consult path for privileged delivery actions; the registry itself stays in `delivery.ts` |
 | `src/host-sweep.ts` | 60s sweep: `processing_ack` sync, stale detection, due-message wake, recurrence |
 | `src/session-manager.ts` | Resolves sessions; opens `inbound.db` / `outbound.db`; manages heartbeat path |
 | `src/container-runner.ts` | Spawns per-agent-group Docker containers with session DB + outbox mounts, OneCLI `ensureAgent` |
-| `src/container-runtime.ts` | Docker CLI wrapper (runtime binary, host-gateway args, mount args), orphan cleanup |
-| `src/guard/` | Privileged-action decision seam: `guard(action, input)` → allow \| hold \| deny. Domain-free leaf; domain decisions are `defineGuardedAction` values exported from module-edge `guard.ts` adapters (cli, agent-to-agent, self-mod, permissions) — consults hold the value, so a missing/typo'd wiring is a compile error, never a fail-open. The keyed registries (ncl commands, delivery actions) demand a guard at registration (derived spec or explicit `unguarded(<reason>)`); broadcast hooks (response handlers, message interceptors) consult the guard inline where privileged. Approved replays carry the approval row as a grant and re-run the structural checks. Policy-as-data (a runtime rules table) is deliberately deferred. Conformance test: `src/guard/conformance.test.ts` |
+| `src/container-runtime.ts` | Runtime selection (Docker vs Apple containers), orphan cleanup |
 | `src/modules/permissions/access.ts` | `canAccessAgentGroup` — owner / global admin / scoped admin / member resolution against `user_roles` + `agent_group_members` |
 | `src/modules/approvals/primitive.ts` | `pickApprover`, `pickApprovalDelivery`, `requestApproval`, approval-handler registry |
 | `src/command-gate.ts` | Router-side admin command gate — queries `user_roles` directly (no env var, no container-side check) |
 | `src/modules/approvals/onecli-approvals.ts` | OneCLI credentialed-action approval bridge |
 | `src/modules/permissions/user-dm.ts` | Cold-DM resolution + `user_dms` cache |
+| `src/audit/` | Opt-in local audit log (`AUDIT_ENABLED=true`): single emit seam + wrappers composed at module edges (dispatch middleware, `requestApproval` decorator, approval-resolved observer, permissions/OneCLI/create-agent seams), append-only NDJSON day-files under `data/audit/`, retention prune, `ncl audit` reader, and `registerAuditHook` — post-write hooks for in-process exporters (fire only after a successful local append). See the "Local Audit Log" section in [docs/SECURITY.md](docs/SECURITY.md) |
 | `src/group-init.ts` | Per-agent-group filesystem scaffold (CLAUDE.md, skills) — agent-runner source is a shared read-only mount, not copied per group |
 | `src/db/container-configs.ts` | CRUD for `container_configs` table (per-group container runtime config) |
 | `src/backfill-container-configs.ts` | Migrates legacy `container.json` files into the DB on startup |
 | `src/container-restart.ts` | Kill + on-wake respawn for agent group containers |
 | `src/db/` | DB layer — agent_groups, messaging_groups, sessions, container_configs, user_roles, user_dms, pending_*, migrations |
 | `src/channels/` | Channel adapter infra (registry, Chat SDK bridge); specific channel adapters are skill-installed from the `channels` branch |
-| `src/channels/channel-defaults.ts` | Wiring-creation helpers over adapter-declared channel defaults (`resolveWiringDefaults`, `resolveThreadPolicy`, engage validation) |
 | `src/providers/` | Host-side provider container-config (`claude` baked in; `opencode` etc. installed from the `providers` branch) |
 | `container/agent-runner/src/` | Agent-runner: poll loop, formatter, provider abstraction, MCP tools, destinations |
-| `container/skills/` | Container skills mounted into every agent session (`agent-browser`, `frontend-engineer`, `onecli-gateway`, `self-customize`, `vercel-cli`, `welcome`; channel-specific skills like `slack-formatting` and `whatsapp-formatting` install with their channel) |
+| `container/skills/` | Container skills mounted into every agent session (`agent-browser`, `frontend-engineer`, `onecli-gateway`, `self-customize`, `slack-formatting`, `vercel-cli`, `welcome`, `whatsapp-formatting`) |
 | `groups/<folder>/` | Per-agent-group filesystem (CLAUDE.md, skills) — agent-runner source is a shared read-only mount, not copied per group |
 | `scripts/init-first-agent.ts` | Bootstrap the first DM-wired agent (used by `/init-first-agent` skill) |
 | `migrate-v2.sh` + `setup/migrate-v2/` | v1→v2 migration. Standalone script: `bash migrate-v2.sh`. Seeds DB, copies groups/sessions, installs channels, builds container, offers service switchover, then hands off to `/migrate-from-v1` skill for owner setup and CLAUDE.md cleanup. See [docs/migration-dev.md](docs/migration-dev.md). |
@@ -108,10 +106,10 @@ ncl help
 | members | list, add, remove | Unprivileged access gate for an agent group |
 | destinations | list, add, remove | Where an agent group can send messages |
 | sessions | list, get | Active sessions (read-only) |
-| tasks | list, get, create, update, cancel, pause, resume, delete, run, append-log | Scheduled tasks for an agent group |
 | user-dms | list | Cold-DM cache (read-only) |
 | dropped-messages | list | Messages from unregistered senders (read-only) |
 | approvals | list, get | Pending approval requests (read-only) |
+| audit | list | Local audit log (read-only; host + global scope only; requires `AUDIT_ENABLED=true`; `--format ndjson` for export) |
 
 Key files: `src/cli/dispatch.ts` (dispatcher + approval handler), `src/cli/crud.ts` (generic CRUD registration), `src/cli/resources/` (per-resource definitions).
 
@@ -119,13 +117,11 @@ Key files: `src/cli/dispatch.ts` (dispatcher + approval handler), `src/cli/crud.
 
 Trunk does not ship any specific channel adapter or non-default agent provider. The codebase is the registry/infra; the actual adapters and providers live on long-lived sibling branches and get copied in by skills:
 
-- **`channels` branch** — Discord, Slack, Telegram, WhatsApp, Teams, Linear, GitHub, iMessage, Webex, Resend, Matrix, Google Chat, WhatsApp Cloud, Signal, WeChat, DeltaChat, Emacs (+ helpers, tests, channel-specific setup steps). Installed via `/add-<channel>` skills.
+- **`channels` branch** — Discord, Slack, Telegram, WhatsApp, Teams, Linear, GitHub, iMessage, Webex, Resend, Matrix, Google Chat, WhatsApp Cloud (+ helpers, tests, channel-specific setup steps). Installed via `/add-<channel>` skills.
 - **`providers` branch** — OpenCode (and any future non-default agent providers). Installed via `/add-opencode`.
 
 Each `/add-<name>` skill is idempotent: `git fetch origin <branch>` → copy module(s) into the standard paths → append a self-registration import to the relevant barrel → `pnpm install <pkg>@<pinned-version>` → build.
 
-**Channel defaults.** Each adapter declares its wiring-time defaults (`ChannelDefaults`: per DM/group context — engage mode/pattern, thread policy, unknown-sender policy — plus mention signaling). Exactly two levels: the adapter declaration, and the per-wiring override chosen at creation — no per-instance DB config table. Undeclared (stale) adapters resolve through a behavior-faithful fallback, so a trunk update alone changes nothing. See [docs/api-details.md](docs/api-details.md#channel-defaults) and `src/channels/channel-defaults.ts`.
-
 ## Self-Modification
 
 One tier of agent self-modification today:
@@ -143,7 +139,7 @@ Per-agent-group container runtime config (provider, model, packages, MCP servers
 | Value | Behavior |
 |-------|----------|
 | `disabled` | Agent never learns about ncl (instructions excluded from CLAUDE.md). Host dispatch rejects any `cli_request`. |
-| `group` (default) | Agent can access `groups`, `sessions`, `destinations`, `members`, `tasks` only, scoped to its own agent group. `--id` and group args are auto-filled. Cross-group access rejected. `cli_scope` changes blocked. |
+| `group` (default) | Agent can access `groups`, `sessions`, `destinations`, `members` only, scoped to its own agent group. `--id` and group args are auto-filled. Cross-group access rejected. `cli_scope` changes blocked. |
 | `global` | Unrestricted. Set automatically for owner agent groups via `init-first-agent`. |
 
 Key files: `src/db/container-configs.ts`, `src/container-config.ts`, `src/cli/dispatch.ts` (scope enforcement), `src/claude-md-compose.ts` (instructions exclusion).
@@ -176,7 +172,7 @@ No container restart needed — the gateway looks up secrets per request.
 
 Approval-gating credentialed actions is a **two-sided** flow:
 
-- **Server-side** (OneCLI gateway): decides *when* to hold a request and emit a pending approval. As of `onecli@2.2.5`, the CLI does **not** expose this — `rules create --action` only accepts `block` or `rate_limit`, and `secrets create` has no approval flag. Approval policies must be configured via the OneCLI web UI at `http://127.0.0.1:10254`. If/when the CLI grows an `approve` action, this section needs updating.
+- **Server-side** (OneCLI gateway): decides *when* to hold a request and emit a pending approval. As of `onecli@1.3.0`, the CLI does **not** expose this — `rules create --action` only accepts `block` or `rate_limit`, and `secrets create` has no approval flag. Approval policies must be configured via the OneCLI web UI at `http://127.0.0.1:10254`. If/when the CLI grows an `approve` action, this section needs updating.
 - **Host-side** (nanoclaw): receives pending approvals and routes them to a human. `src/modules/approvals/onecli-approvals.ts` registers a callback via `onecli.configureManualApproval(cb)` (long-polls `GET /api/approvals/pending`). The callback uses `pickApprover` + `pickApprovalDelivery` from `src/modules/approvals/primitive.ts` to DM an approver. Approvers are resolved from the `user_roles` table — preference order: scoped admins for the agent group → global admins → owners. There is no env var like `NANOCLAW_ADMIN_USER_IDS`; roles are persisted in the central DB only.
 
 If approvals are configured server-side but the host callback isn't running (or throws), every credentialed call hangs until the gateway times out. Conversely, if the gateway has no rule asking for approval, the host callback never fires regardless of how it's wired.
@@ -188,7 +184,7 @@ Four types of skills. See [CONTRIBUTING.md](CONTRIBUTING.md) for the full taxono
 - **Channel/provider install skills** — copy the relevant module(s) in from the `channels` or `providers` branch, wire imports, install pinned deps (e.g. `/add-discord`, `/add-slack`, `/add-whatsapp`, `/add-opencode`).
 - **Utility skills** — ship code files alongside `SKILL.md` (e.g. a `scripts/` CLI or helper).
 - **Operational skills** — instruction-only workflows (`/setup`, `/debug`, `/customize`, `/init-first-agent`, `/manage-channels`, `/init-onecli`, `/update-nanoclaw`).
-- **Container skills** — loaded inside agent containers at runtime (`container/skills/`: `agent-browser`, `frontend-engineer`, `onecli-gateway`, `self-customize`, `vercel-cli`, `welcome`; channel-specific skills like `slack-formatting` and `whatsapp-formatting` are copied in by their `/add-<channel>` skill).
+- **Container skills** — loaded inside agent containers at runtime (`container/skills/`: `agent-browser`, `frontend-engineer`, `onecli-gateway`, `self-customize`, `slack-formatting`, `vercel-cli`, `welcome`, `whatsapp-formatting`).
 
 | Skill | When to Use |
 |-------|-------------|
@@ -222,7 +218,7 @@ Run commands directly — don't tell the user to run them.
 
 ```bash
 # Host (Node + pnpm)
-pnpm run dev          # Host via tsx (no watch)
+pnpm run dev          # Host with hot reload
 pnpm run build        # Compile host TypeScript (src/)
 ./container/build.sh  # Rebuild agent container image (nanoclaw-agent:latest)
 pnpm test             # Host tests (vitest)
@@ -257,13 +253,6 @@ Check these first when something goes wrong:
 
 Note: container logs are lost after the container exits (`--rm` flag). If the agent silently failed inside the container, there's no persistent log to inspect.
 
-## Timestamps
-
-Two rules, no exceptions:
-
-- **Storage**: every timestamp written from JS is `new Date().toISOString()` (ISO-8601 UTC with `Z`). Never `datetime('now')` — its naive `YYYY-MM-DD HH:MM:SS` shape is misparsed as local time by `new Date()` and breaks string comparisons against ISO values. In pure-SQL contexts (skill snippets) use `strftime('%Y-%m-%dT%H:%M:%fZ','now')`. SQL-side *comparisons* wrap both sides in `datetime()`.
-- **Display**: anything shown to an agent or a user renders in the install timezone — `formatLocalTime` (prose) or `formatLocalStamp` (log lines) from `src/timezone.ts` / `container/agent-runner/src/timezone.ts`. `--json` output, DB values, and operator logs stay ISO.
-
 ## Supply Chain Security (pnpm)
 
 This project uses pnpm with `minimumReleaseAge: 4320` (3 days) in `pnpm-workspace.yaml`. New package versions must exist on the npm registry for 3 days before pnpm will resolve them.
@@ -310,7 +299,7 @@ The agent container runs on **Bun**; the host runs on **Node** (pnpm). They comm
 - **Writing a new named-param SQL insert/update in the container** → use `$name` in both SQL and JS keys: `.run({ $id: msg.id })`. `bun:sqlite` does not auto-strip the prefix the way `better-sqlite3` does on the host. Positional `?` params work normally.
 - **Adding a test in `container/agent-runner/src/`** → import from `bun:test`, not `vitest`. Vitest runs on Node and can't load `bun:sqlite`. `vitest.config.ts` excludes this tree.
 - **Adding a Node CLI the agent invokes at runtime** (like `agent-browser`, `claude-code`, `vercel`) → put it in the Dockerfile's pnpm global-install block, pinned to an exact version via a new `ARG`. Don't use `bun install -g` — that bypasses the pnpm supply-chain policy.
-- **Changing the Dockerfile entrypoint or the dynamic-spawn command** (`src/container-runner.ts` line ~503) → keep `exec bun ...` so signals forward cleanly. The image has no `/app/dist`; don't reintroduce a tsc build step.
+- **Changing the Dockerfile entrypoint or the dynamic-spawn command** (`src/container-runner.ts` line ~301) → keep `exec bun ...` so signals forward cleanly. The image has no `/app/dist`; don't reintroduce a tsc build step.
 - **Changing session-DB pragmas** (`container/agent-runner/src/db/connection.ts`) → `journal_mode=DELETE` is load-bearing for cross-mount visibility. Read the comment block at the top of the file first.
 
 ## CJK font support

CONTRIBUTING.md

@@ -75,7 +75,7 @@ Standalone tools that ship code files alongside the SKILL.md. The SKILL.md tells
 
 #### 3. Operational skills (instruction-only)
 
-Workflows and guides with no code changes. The SKILL.md is the entire skill — the coding agent follows the instructions to perform a task.
+Workflows and guides with no code changes. The SKILL.md is the entire skill — Claude follows the instructions to perform a task.
 
 **Location:** `.claude/skills/` on `main`
 
@@ -88,13 +88,13 @@ Workflows and guides with no code changes. The SKILL.md is the entire skill —
 
 #### 4. Container skills (agent runtime)
 
-Skills that run inside the agent container, not on the host. These teach the NanoClaw agent how to use tools, format output, or perform tasks. They are synced into each group's `.claude/skills/` directory when a container starts.
+Skills that run inside the agent container, not on the host. These teach the container agent how to use tools, format output, or perform tasks. They are synced into each group's `.claude/skills/` directory when a container starts.
 
 **Location:** `container/skills/<name>/`
 
-**Examples:** `agent-browser` (web browsing), `frontend-engineer`, `onecli-gateway` (OneCLI proxy usage), `self-customize`, `vercel-cli`, `welcome`; channel-specific: `slack-formatting` (Slack mrkdwn syntax) and `whatsapp-formatting` (channels branch; installed by `/add-slack` / `/add-whatsapp`)
+**Examples:** `agent-browser` (web browsing), `capabilities` (/capabilities command), `status` (/status command), `slack-formatting` (Slack mrkdwn syntax)
 
-**Key difference:** You never invoke these from a coding-agent session on the host, the way you run `/setup` or `/update-nanoclaw` in Claude Code/Codex/OpenCode. They're mounted into the sandbox and loaded by the NanoClaw agent itself, shaping how it behaves when you chat with it.
+**Key difference:** These are NOT invoked by the user on the host. They're loaded by Claude Code inside the container and influence how the agent behaves.
 
 **Guidelines:**
 - Follow the same SKILL.md + frontmatter format

README.md

@@ -22,7 +22,7 @@
 
 [OpenClaw](https://github.com/openclaw/openclaw) is an impressive project, but I wouldn't have been able to sleep if I had given complex software I didn't understand full access to my life. OpenClaw has nearly half a million lines of code, 53 config files, and 70+ dependencies. Its security is at the application level (allowlists, pairing codes) rather than true OS-level isolation. Everything runs in one Node process with shared memory.
 
-NanoClaw provides that same core functionality, but in a codebase small enough to understand: one process and a handful of files. Agents run in their own Linux containers with filesystem isolation, not merely behind permission checks.
+NanoClaw provides that same core functionality, but in a codebase small enough to understand: one process and a handful of files. Claude agents run in their own Linux containers with filesystem isolation, not merely behind permission checks.
 
 ## Quick Start
 
@@ -49,7 +49,7 @@ bash migrate-v2.sh
 
 Run the script directly, not from inside a Claude session — the deterministic side needs interactive prompts and real shell I/O for Node/pnpm bootstrap, Docker, OneCLI, and the container build.
 
-**What it does:** merges `.env`, seeds the v2 DB from `registered_groups`, copies group folders + session data + scheduled tasks, installs the channel adapters you select, copies channel auth state (including the Baileys keystore for WhatsApp — LID mapping is now resolved per-message by the Baileys v7 adapter, not migrated), builds the agent container.
+**What it does:** merges `.env`, seeds the v2 DB from `registered_groups`, copies group folders + session data + scheduled tasks, installs the channel adapters you select, copies channel auth state (including Baileys keystore + LID mappings for WhatsApp), builds the agent container.
 
 **What it doesn't:** flip the system service. Pick *"switch to v2"* at the prompt, or do it manually after testing — your v1 install is left untouched.
 
@@ -78,11 +78,11 @@ See [docs/v1-to-v2-changes.md](docs/v1-to-v2-changes.md) for what's different an
 - **Multi-channel messaging** — WhatsApp, Telegram, Discord, Slack, Microsoft Teams, iMessage, Matrix, Google Chat, Webex, Linear, GitHub, WeChat, and email via Resend. Installed on demand with `/add-<channel>` skills. Run one or many at the same time.
 - **Flexible isolation** — connect each channel to its own agent for full privacy, share one agent across many channels for unified memory with separate conversations, or fold multiple channels into a single shared session so one conversation spans many surfaces. Pick per channel via `/manage-channels`. See [docs/isolation-model.md](docs/isolation-model.md).
 - **Per-agent workspace** — each agent group has its own `CLAUDE.md`, its own memory, its own container, and only the mounts you allow. Nothing crosses the boundary unless you wire it to.
-- **Scheduled tasks** — recurring jobs executed by the agent, which can message you the results
+- **Scheduled tasks** — recurring jobs that run Claude and can message you back
 - **Web access** — search and fetch content from the web
-- **Container isolation** — agents are sandboxed in Docker containers (macOS/Linux/WSL2)
+- **Container isolation** — agents are sandboxed in Docker (macOS/Linux/WSL2), with optional Docker Sandboxes micro-VM isolation
 - **Credential security** — agents never hold raw API keys. Outbound requests route through [OneCLI's Agent Vault](https://github.com/onecli/onecli), which injects credentials at request time and enforces per-agent policies and rate limits.
-- **Agent templates**: stamp a ready-to-run agent (instructions + MCP tools + skills, no secrets) from a reusable bundle via `ncl groups create --template <ref>`. Templates load from the local `templates/` folder; populate it by hand or by copying from the [public library](https://github.com/nanocoai/nanoclaw-templates). See [docs/templates.md](docs/templates.md).
+- **Agent templates**: stamp a ready-to-run agent (instructions + MCP tools + skills, no secrets) from a reusable bundle, via the setup wizard or `ncl groups create --template <ref>`. Load from the [public library](https://github.com/nanocoai/nanoclaw-templates), a local folder, or any git repo. See [docs/templates.md](docs/templates.md).
 
 ## Usage
 
@@ -124,7 +124,10 @@ This keeps trunk as pure registry and infra, and every fork stays lean — users
 
 ### RFS (Request for Skills)
 
-No channel or provider skills are currently requested — propose one via an issue.
+Skills we'd like to see:
+
+**Communication Channels**
+- `/add-signal` — Add Signal as a channel
 
 ## Requirements
 
@@ -139,7 +142,7 @@ No channel or provider skills are currently requested — propose one via an iss
 messaging apps → host process (router) → inbound.db → container (Bun, Claude Agent SDK) → outbound.db → host process (delivery) → messaging apps
 ```
 
-A single Node host orchestrates per-session agent containers. When a message arrives, the host routes it via the entity model (user → messaging group → agent group → session), writes it to the session's `inbound.db`, and wakes the container. The agent-runner inside the container polls `inbound.db`, runs the agent, and writes responses to `outbound.db`. The host polls `outbound.db` and delivers back through the channel adapter.
+A single Node host orchestrates per-session agent containers. When a message arrives, the host routes it via the entity model (user → messaging group → agent group → session), writes it to the session's `inbound.db`, and wakes the container. The agent-runner inside the container polls `inbound.db`, runs Claude, and writes responses to `outbound.db`. The host polls `outbound.db` and delivers back through the channel adapter.
 
 Two SQLite files per session, each with exactly one writer — no cross-mount contention, no IPC, no stdin piping. Channels and alternative providers self-register at startup; trunk ships the registry and the Chat SDK bridge, while the adapters themselves are skill-installed per fork.
 
@@ -162,7 +165,7 @@ Key files:
 
 **Why Docker?**
 
-Docker provides cross-platform support (macOS, Linux and Windows via WSL2) and a mature ecosystem.
+Docker provides cross-platform support (macOS, Linux and Windows via WSL2) and a mature ecosystem. For additional isolation, Docker Sandboxes run each container inside a micro VM.
 
 **Can I run this on Linux or Windows?**
 

container/agent-runner/src/cli/ncl.ts

@@ -22,9 +22,7 @@ type RequestFrame = {
 };
 
 type ResponseFrame =
-  // `human` mirrors src/cli/frame.ts: an optional server-rendered string we
-  // print verbatim instead of running our own (drift-prone) formatter.
-  | { id: string; ok: true; data: unknown; human?: string }
+  | { id: string; ok: true; data: unknown }
   | { id: string; ok: false; error: { code: string; message: string } };
 
 // ---------------------------------------------------------------------------
@@ -65,11 +63,10 @@ function writeRequest(req: RequestFrame): void {
 
     db.prepare(
       `INSERT INTO messages_out (id, seq, timestamp, kind, content)
-       VALUES ($id, $seq, $timestamp, 'system', $content)`,
+       VALUES ($id, $seq, datetime('now'), 'system', $content)`,
     ).run({
       $id: req.id,
       $seq: nextSeq,
-      $timestamp: new Date().toISOString(),
       $content: JSON.stringify({
         action: 'cli_request',
         requestId: req.id,
@@ -111,9 +108,9 @@ function pollResponse(requestId: string, timeoutMs: number): ResponseFrame | nul
         outDb.exec('PRAGMA busy_timeout = 5000');
         outDb
           .prepare(
-            "INSERT OR REPLACE INTO processing_ack (message_id, status, status_changed) VALUES (?, 'completed', ?)",
+            "INSERT OR REPLACE INTO processing_ack (message_id, status, status_changed) VALUES (?, 'completed', datetime('now'))",
           )
-          .run(row.id, new Date().toISOString());
+          .run(row.id);
         outDb.close();
 
         const parsed = JSON.parse(row.content);
@@ -185,46 +182,12 @@ function printUsage(): void {
 // Formatting (mirrors src/cli/format.ts on the host)
 // ---------------------------------------------------------------------------
 
-// Mirrors localizeIsoTimestamps in src/cli/format.ts (self-contained — no
-// imports from agent-runner). Human display shows local time (container TZ
-// env = install timezone); --json keeps the ISO machine contract. Only whole
-// ISO-instant strings convert — embedded occurrences may be machine payloads.
-const ISO_UTC_RE = /^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}(:\d{2}(\.\d+)?)?Z$/;
-
-// "YYYY-MM-DD HH:mm" — round-trips through parseZonedToUtc (naive = local
-// wall-clock), so a value copied from human output into --process-after
-// means what it shows.
-function localTime(iso: string): string {
-  return new Date(iso).toLocaleString('sv-SE', {
-    timeZone: process.env.TZ || 'UTC',
-    year: 'numeric',
-    month: '2-digit',
-    day: '2-digit',
-    hour: '2-digit',
-    minute: '2-digit',
-    hour12: false,
-  });
-}
-
-function localizeIsoTimestamps(value: unknown): unknown {
-  if (typeof value === 'string') {
-    return ISO_UTC_RE.test(value) ? localTime(value) : value;
-  }
-  if (Array.isArray(value)) return value.map(localizeIsoTimestamps);
-  if (value && typeof value === 'object') {
-    return Object.fromEntries(
-      Object.entries(value as Record<string, unknown>).map(([k, v]) => [k, localizeIsoTimestamps(v)]),
-    );
-  }
-  return value;
-}
-
 function formatHuman(resp: ResponseFrame): string {
   if (!resp.ok) {
     return `error (${resp.error.code}): ${resp.error.message}\n`;
   }
 
-  const data = localizeIsoTimestamps(resp.data);
+  const data = resp.data;
   if (!Array.isArray(data) || data.length === 0) {
     return JSON.stringify(data, null, 2) + '\n';
   }
@@ -281,9 +244,6 @@ if (!resp) {
 
 if (json) {
   process.stdout.write(JSON.stringify(resp, null, 2) + '\n');
-} else if (resp.ok && resp.human !== undefined) {
-  // Server-rendered view — print verbatim.
-  process.stdout.write(resp.human + '\n');
 } else {
   const output = formatHuman(resp);
   if (!resp.ok) {

container/agent-runner/src/db/messages-in.ts

@@ -101,10 +101,10 @@ export function markProcessing(ids: string[]): void {
   if (ids.length === 0) return;
   const db = getOutboundDb();
   const stmt = db.prepare(
-    "INSERT OR REPLACE INTO processing_ack (message_id, status, status_changed) VALUES (?, 'processing', ?)",
+    "INSERT OR REPLACE INTO processing_ack (message_id, status, status_changed) VALUES (?, 'processing', datetime('now'))",
   );
   db.transaction(() => {
-    for (const id of ids) stmt.run(id, new Date().toISOString());
+    for (const id of ids) stmt.run(id);
   })();
 }
 
@@ -113,28 +113,10 @@ export function markCompleted(ids: string[]): void {
   if (ids.length === 0) return;
   const db = getOutboundDb();
   const stmt = db.prepare(
-    "INSERT OR REPLACE INTO processing_ack (message_id, status, status_changed) VALUES (?, 'completed', ?)",
+    "INSERT OR REPLACE INTO processing_ack (message_id, status, status_changed) VALUES (?, 'completed', datetime('now'))",
   );
   db.transaction(() => {
-    for (const id of ids) stmt.run(id, new Date().toISOString());
-  })();
-}
-
-/**
- * Ack task messages whose pre-task script gated the run. The reason decides
- * the ack: `gated` (wakeAgent=false) is the monitor working as designed → a
- * plain `completed`; `error` (broken script) → `script-skip:error`, which the
- * host's ack sync records as a FAILED run so recurrence can read the trailing
- * failed streak off the occurrence rows and back the series off.
- */
-export function markScriptSkipped(skips: Array<{ id: string; reason: string }>): void {
-  if (skips.length === 0) return;
-  const db = getOutboundDb();
-  const stmt = db.prepare(
-    'INSERT OR REPLACE INTO processing_ack (message_id, status, status_changed) VALUES (?, ?, ?)',
-  );
-  db.transaction(() => {
-    for (const s of skips) stmt.run(s.id, s.reason === 'error' ? 'script-skip:error' : 'completed', new Date().toISOString());
+    for (const id of ids) stmt.run(id);
   })();
 }
 
@@ -142,9 +124,9 @@ export function markScriptSkipped(skips: Array<{ id: string; reason: string }>):
 export function markFailed(id: string): void {
   getOutboundDb()
     .prepare(
-      "INSERT OR REPLACE INTO processing_ack (message_id, status, status_changed) VALUES (?, 'failed', ?)",
+      "INSERT OR REPLACE INTO processing_ack (message_id, status, status_changed) VALUES (?, 'failed', datetime('now'))",
     )
-    .run(id, new Date().toISOString());
+    .run(id);
 }
 
 /** Get a message by ID (read from inbound.db). */

container/agent-runner/src/db/messages-out.ts

@@ -58,12 +58,11 @@ export function writeMessageOut(msg: WriteMessageOut): number {
   outbound
     .prepare(
       `INSERT INTO messages_out (id, seq, in_reply_to, timestamp, deliver_after, recurrence, kind, platform_id, channel_type, thread_id, content)
-     VALUES ($id, $seq, $in_reply_to, $timestamp, $deliver_after, $recurrence, $kind, $platform_id, $channel_type, $thread_id, $content)`,
+     VALUES ($id, $seq, $in_reply_to, datetime('now'), $deliver_after, $recurrence, $kind, $platform_id, $channel_type, $thread_id, $content)`,
     )
     .run({
       $id: msg.id,
       $seq: nextSeq,
-      $timestamp: new Date().toISOString(),
       $in_reply_to: msg.in_reply_to ?? null,
       $deliver_after: msg.deliver_after ?? null,
       $recurrence: msg.recurrence ?? null,
@@ -137,27 +136,8 @@ export function getUndeliveredMessages(): MessageOutRow[] {
   return getOutboundDb()
     .prepare(
       `SELECT * FROM messages_out
-       WHERE (deliver_after IS NULL OR datetime(deliver_after) <= datetime('now'))
+       WHERE (deliver_after IS NULL OR deliver_after <= datetime('now'))
        ORDER BY timestamp ASC`,
     )
     .all() as MessageOutRow[];
 }
-
-/**
- * True if a deliberate send with this exact destination + text already exists
- * (an MCP send_message row from the current turn). Used by the task-fire
- * final-text dispatcher to drop the turn-final <message> echo of a send the
- * agent already made — the dedup happens where the duplication originates.
- */
-export function hasIdenticalSend(platformId: string, channelType: string, text: string): boolean {
-  const row = getOutboundDb()
-    .prepare(
-      `SELECT 1 FROM messages_out
-        WHERE platform_id = $platform_id AND channel_type = $channel_type
-          AND (in_reply_to IS NULL OR in_reply_to = '')
-          AND json_extract(content, '$.text') = $text
-        LIMIT 1`,
-    )
-    .get({ $platform_id: platformId, $channel_type: channelType, $text: text });
-  return row != null;
-}

container/agent-runner/src/destinations.ts

@@ -105,11 +105,13 @@ function buildDestinationsSection(): string {
   const lines = ['## Sending messages', ''];
   if (all.length === 1) {
     const d = all[0];
-    lines.push(`Your destination is \`${d.name}\`${destinationLabel(d)}.`);
+    const label = d.displayName && d.displayName !== d.name ? ` (${d.displayName})` : '';
+    lines.push(`Your destination is \`${d.name}\`${label}.`);
   } else {
     lines.push('You can send messages to the following destinations:', '');
     for (const d of all) {
-      lines.push(`- \`${d.name}\`${destinationLabel(d)}`);
+      const label = d.displayName && d.displayName !== d.name ? ` (${d.displayName})` : '';
+      lines.push(`- \`${d.name}\`${label}`);
     }
   }
   lines.push('');
@@ -126,10 +128,3 @@ function buildDestinationsSection(): string {
   );
   return lines.join('\n');
 }
-
-function destinationLabel(d: DestinationEntry): string {
-  const parts: string[] = [];
-  if (d.channelType) parts.push(d.channelType);
-  if (d.displayName && d.displayName !== d.name) parts.push(d.displayName);
-  return parts.length > 0 ? ` (${parts.join(' · ')})` : '';
-}

container/agent-runner/src/formatter.test.ts

@@ -14,7 +14,7 @@ import { describe, it, expect, beforeEach, afterEach } from 'bun:test';
 import { initTestSessionDb, closeSessionDb, getInboundDb } from './db/connection.js';
 import { getPendingMessages } from './db/messages-in.js';
 import { formatMessages, stripInternalTags } from './formatter.js';
-import { TIMEZONE, formatLocalTime } from './timezone.js';
+import { TIMEZONE } from './timezone.js';
 
 beforeEach(() => {
   initTestSessionDb();
@@ -109,14 +109,6 @@ describe('timestamp formatting', () => {
   });
 });
 
-describe('task timestamps', () => {
-  it('renders task time in the user TZ, same as chat rows', () => {
-    insertMessage('t1', 'task', { prompt: 'do the thing' }, { timestamp: '2026-01-05T12:00:00.000Z' });
-    const result = formatMessages(getPendingMessages());
-    expect(result).toContain(`time="${formatLocalTime('2026-01-05T12:00:00.000Z', TIMEZONE)}"`);
-  });
-});
-
 describe('reply_to + quoted_message rendering', () => {
   it('renders reply_to attribute and quoted_message when all fields present', () => {
     insertMessage('m1', 'chat', {

container/agent-runner/src/formatter.ts

@@ -98,11 +98,6 @@ export interface RoutingContext {
   channelType: string | null;
   threadId: string | null;
   inReplyTo: string | null;
-  /** Batch is a task fire — explicit `<message to>` sends must NOT inherit
-   *  inReplyTo (the series id), or the host's task-fire suppression drops
-   *  them as turn-final echoes: zero delivery. Deliberate sends are
-   *  in_reply_to-null, same as the out-of-process MCP send_message path. */
-  taskFire: boolean;
 }
 
 /**
@@ -116,7 +111,6 @@ export function extractRouting(messages: MessageInRow[]): RoutingContext {
     channelType: first?.channel_type ?? null,
     threadId: first?.thread_id ?? null,
     inReplyTo: first?.id ?? null,
-    taskFire: messages.length > 0 && messages.every((m) => m.kind === 'task'),
   };
 }
 

container/agent-runner/src/mcp-tools/cli.instructions.md

@@ -18,13 +18,12 @@ Your CLI access may be scoped. Run `ncl help` to see which resources are availab
 
 Run `ncl help` for the full list. Common resources:
 
-| Resource     | Verbs                                                                                                                                     | What it is                                              |
-| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- |
-| groups       | list, get, create, update, delete, restart, config get/update, config add-mcp-server/remove-mcp-server, config add-package/remove-package | Agent groups (workspace, personality, container config) |
-| sessions     | list, get                                                                                                                                 | Active sessions (read-only)                             |
-| destinations | list, add, remove                                                                                                                         | Where an agent group can send messages                  |
-| members      | list, add, remove                                                                                                                         | Unprivileged access gate for an agent group             |
-| tasks        | list, get, create, update, cancel, pause, resume, delete, append-log                                                                      | Scheduled tasks for your agent group                    |
+| Resource | Verbs | What it is |
+|----------|-------|------------|
+| groups | list, get, create, update, delete, restart, config get/update, config add-mcp-server/remove-mcp-server, config add-package/remove-package | Agent groups (workspace, personality, container config) |
+| sessions | list, get | Active sessions (read-only) |
+| destinations | list, add, remove | Where an agent group can send messages |
+| members | list, add, remove | Unprivileged access gate for an agent group |
 
 Additional resources (available under `global` scope only): messaging-groups, wirings, users, roles, user-dms, dropped-messages, approvals.
 
@@ -34,12 +33,11 @@ Additional resources (available under `global` scope only): messaging-groups, wi
 - **Restarting your container** — `ncl groups restart` (with optional `--rebuild` and `--message`).
 - **Checking who's in your group** — `ncl members list`.
 - **Seeing your destinations** — `ncl destinations list`.
-- **Scheduling work** — `ncl tasks create`, then `ncl tasks list/get/update/cancel/pause/resume/delete`; `ncl tasks run <id>` fires one extra run now (testing) without changing the schedule. At the end of each task run, `ncl tasks append-log --msg "…"` to record what happened (host-timestamped, not a message).
 - **Answering questions about the system** — query `ncl` rather than guessing.
 
 ### Access rules
 
-Read commands (list, get) are open. Most write commands (create, update, delete, restart, config update, add, remove) require admin approval — the request is held until an admin approves it. `ncl tasks` is the exception: an agent can manage its own group tasks without approval.
+Read commands (list, get) are open. Write commands (create, update, delete, restart, config update, add, remove) require admin approval — the request is held until an admin approves it.
 
 ### Approval flow
 
@@ -63,13 +61,6 @@ ncl groups config get
 ncl sessions list
 ncl destinations list
 ncl members list
-ncl tasks list
-# Always pass a short descriptive --name so the task id is readable (e.g. daily-briefing-a25c, not a long uuid).
-# For a recurring task, --recurrence alone sets the schedule (first run derived from it); add --process-after only for one-shots.
-ncl tasks create --name "daily briefing" --prompt "Send the daily briefing" --recurrence "0 9 * * *"
-# At the END of every task run, record one line of history. The host stamps the local time — you supply only the summary.
-# This is a LOG ENTRY, not a message: it sends nothing to anyone. Inside a task fire --id is auto-derived from your session.
-ncl tasks append-log --msg "posted the daily digest to slack; one feed returned 403, skipped"
 
 # Write commands (approval required)
 ncl groups restart

container/agent-runner/src/mcp-tools/index.ts

@@ -6,6 +6,7 @@
  * at module scope, and append the import here. No central list.
  */
 import './core.js';
+import './scheduling.js';
 import './interactive.js';
 import './agents.js';
 import './self-mod.js';

container/agent-runner/src/mcp-tools/scheduling.instructions.md

@@ -1,25 +1,40 @@
-## Task scheduling (`ncl tasks`)
+## Task scheduling (`schedule_task`)
 
-Use `ncl tasks` for one-shot and recurring tasks. A task runs in this agent group's system session, not in the current chat session, so when it fires you must choose a destination explicitly with `<message to="name">...</message>` or `send_message({ to: "name", ... })`.
+For any recurring task, use `schedule_task`. This is the scheduling path — tasks persist across sessions and restarts, and support the pre-task `script` hook described below.
 
-Pass `--name "<short label>"` on create to get a readable task id (e.g. `--name "sales briefing"` → `sales-briefing-a25c`); without it ids are `t-<hex>`.
+To inspect or change existing tasks, use `list_tasks` (returns one row per series with the stable id) and `update_task` / `cancel_task` / `pause_task` / `resume_task`. Prefer `update_task` over cancel + reschedule.
 
-Common commands:
+Frequent recurring scheduled tasks — more than a few times a day — consume API credits and can risk account restrictions. You can add a `script` that runs first, and you will only be called when the check passes.
+
+### How it works
+
+1. Provide a bash `script` alongside the `prompt` when scheduling
+2. When the task fires, the script runs first
+3. Script returns: `{ "wakeAgent": true/false, "data": {...} }`
+4. If `wakeAgent: false` — nothing happens, task waits for next run
+5. If `wakeAgent: true` — claude receives the script's data + prompt and handles
+
+### Always test your script first
+
+Before scheduling, run the script directly to verify it works:
 
 ```bash
-ncl tasks create --name "ping" --prompt "Remind me to call Dana" --process-after "tomorrow 18:00"
-ncl tasks list
-ncl tasks get ping-a25c        # includes run count, failures, and recent run-log lines
-ncl tasks run ping-a25c         # fire once now without changing the schedule (testing)
-ncl tasks update ping-a25c --prompt "New instructions"
-ncl tasks pause ping-a25c
-ncl tasks resume ping-a25c
-ncl tasks cancel ping-a25c      # or --all as a kill switch
-ncl tasks delete ping-a25c
+bash -c 'node --input-type=module -e "
+  const r = await fetch(\"https://api.github.com/repos/owner/repo/pulls?state=open\");
+  const prs = await r.json();
+  console.log(JSON.stringify({ wakeAgent: prs.length > 0, data: prs.slice(0, 5) }));
+"'
 ```
 
-Use good judgement on whether it's appropriate to check in with the user about the task prompt before task creation, and if so, whether to share verbatim or a description of it.
+### When NOT to use scripts
 
-`--process-after` accepts UTC timestamps or naive local timestamps interpreted in the instance timezone (shown in the `<context timezone="..."/>` header).
+If a task requires your judgment every time (daily briefings, reminders, reports), skip the script — just use a regular prompt. Do not attempt to do things like sentiment analysis or advanced nlp in scripts.
 
-Run `ncl tasks create --help` for schedules, options, and pre-task gate scripts (checks that run before you wake).
+### Frequent task guidance
+
+If a user wants a task to run more than a few times a day and a script can't be used:
+
+- Explain that each time the task fires it uses API credits and risks rate limits
+- Suggest adjusting the task requirements in a way that will allow you to use a script
+- If the user needs an LLM to evaluate data, suggest using an API key with direct Anthropic API calls inside the script
+- Help the user find the minimum viable frequency

container/agent-runner/src/mcp-tools/scheduling.ts

@@ -0,0 +1,302 @@
+/**
+ * Scheduling MCP tools: schedule_task, list_tasks, cancel_task, pause_task, resume_task.
+ *
+ * With the two-DB split, the container cannot write to inbound.db (host-owned).
+ * Scheduling operations are sent as system actions via messages_out — the host
+ * reads them during delivery and applies the changes to inbound.db.
+ */
+import { getInboundDb } from '../db/connection.js';
+import { writeMessageOut } from '../db/messages-out.js';
+import { getSessionRouting } from '../db/session-routing.js';
+import { TIMEZONE, parseZonedToUtc } from '../timezone.js';
+import { registerTools } from './server.js';
+import type { McpToolDefinition } from './types.js';
+
+function log(msg: string): void {
+  console.error(`[mcp-tools] ${msg}`);
+}
+
+function generateId(): string {
+  return `task-${Date.now()}-${Math.random().toString(36).slice(2, 8)}`;
+}
+
+function routing() {
+  return getSessionRouting();
+}
+
+function ok(text: string) {
+  return { content: [{ type: 'text' as const, text }] };
+}
+
+function err(text: string) {
+  return { content: [{ type: 'text' as const, text: `Error: ${text}` }], isError: true };
+}
+
+export const scheduleTask: McpToolDefinition = {
+  tool: {
+    name: 'schedule_task',
+    description:
+      `Schedule a one-shot or recurring task. The user's timezone is declared in the <context timezone="..."/> header of your prompt — interpret the user's "9pm" etc. in that zone. Cron expressions are interpreted in the user's timezone too.`,
+    inputSchema: {
+      type: 'object' as const,
+      properties: {
+        prompt: { type: 'string', description: 'Task instructions/prompt' },
+        processAfter: {
+          type: 'string',
+          description:
+            `ISO 8601 timestamp for the first run. Accepts either UTC (ending in "Z" or "+00:00") or a naive local timestamp (no offset) which is interpreted in the user's timezone (e.g. "2026-01-15T21:00:00" = 9pm user-local). Prefer naive local.`,
+        },
+        recurrence: {
+          type: 'string',
+          description:
+            'Cron expression for recurring tasks (e.g., "0 9 * * 1-5" = weekdays at 9am user-local). Evaluated in the user\'s timezone.',
+        },
+        script: { type: 'string', description: 'Optional pre-agent script to run before processing' },
+      },
+      required: ['prompt', 'processAfter'],
+    },
+  },
+  async handler(args) {
+    const prompt = args.prompt as string;
+    const processAfterIn = args.processAfter as string;
+    if (!prompt || !processAfterIn) return err('prompt and processAfter are required');
+
+    let processAfter: string;
+    try {
+      const d = parseZonedToUtc(processAfterIn, TIMEZONE);
+      if (Number.isNaN(d.getTime())) return err(`invalid processAfter: ${processAfterIn}`);
+      processAfter = d.toISOString();
+    } catch {
+      return err(`invalid processAfter: ${processAfterIn}`);
+    }
+
+    const id = generateId();
+    const r = routing();
+    const recurrence = (args.recurrence as string) || null;
+    const script = (args.script as string) || null;
+
+    // Write as a system action — host will insert into inbound.db
+    writeMessageOut({
+      id,
+      kind: 'system',
+      platform_id: r.platform_id,
+      channel_type: r.channel_type,
+      thread_id: r.thread_id,
+      content: JSON.stringify({
+        action: 'schedule_task',
+        taskId: id,
+        prompt,
+        script,
+        processAfter,
+        recurrence,
+        platformId: r.platform_id,
+        channelType: r.channel_type,
+        threadId: r.thread_id,
+      }),
+    });
+
+    log(`schedule_task: ${id} at ${processAfter}${recurrence ? ` (recurring: ${recurrence})` : ''}`);
+    return ok(`Task scheduled (id: ${id}, runs at: ${processAfter}${recurrence ? `, recurrence: ${recurrence}` : ''})`);
+  },
+};
+
+export const listTasks: McpToolDefinition = {
+  tool: {
+    name: 'list_tasks',
+    description:
+      'List scheduled tasks. Returns one row per series — the live (pending or paused) occurrence. The id shown is the series id, which is what update_task / cancel_task / pause_task / resume_task expect.',
+    inputSchema: {
+      type: 'object' as const,
+      properties: {
+        status: { type: 'string', description: 'Filter by status: pending or paused (default: both)' },
+      },
+    },
+  },
+  async handler(args) {
+    const status = args.status as string | undefined;
+    const db = getInboundDb();
+    // One row per series — the live (pending or paused) occurrence. Recurring
+    // tasks accumulate one completed row per firing plus one live follow-up;
+    // exposing the whole pile to the agent is noisy and confuses task identity
+    // ("which id do I cancel?"). The series_id is the stable handle.
+    //
+    // SQLite quirk: when MAX(seq) appears in the SELECT list of a GROUP BY
+    // query, the bare columns take values from the row that contains that max
+    // — that's how we pick "the latest live row per series" in one pass.
+    let rows;
+    if (status) {
+      rows = db
+        .prepare(
+          `SELECT series_id AS id, status, process_after, recurrence, content, MAX(seq) AS _seq
+             FROM messages_in
+            WHERE kind = 'task' AND status = ?
+            GROUP BY series_id
+            ORDER BY process_after ASC`,
+        )
+        .all(status);
+    } else {
+      rows = db
+        .prepare(
+          `SELECT series_id AS id, status, process_after, recurrence, content, MAX(seq) AS _seq
+             FROM messages_in
+            WHERE kind = 'task' AND status IN ('pending', 'paused')
+            GROUP BY series_id
+            ORDER BY process_after ASC`,
+        )
+        .all();
+    }
+
+    if ((rows as unknown[]).length === 0) return ok('No tasks found.');
+
+    const lines = (rows as Array<{ id: string; status: string; process_after: string | null; recurrence: string | null; content: string }>).map((r) => {
+      const content = JSON.parse(r.content);
+      const prompt = (content.prompt as string || '').slice(0, 80);
+      return `- ${r.id} [${r.status}] at=${r.process_after || 'now'} ${r.recurrence ? `recur=${r.recurrence} ` : ''}→ ${prompt}`;
+    });
+
+    return ok(lines.join('\n'));
+  },
+};
+
+export const cancelTask: McpToolDefinition = {
+  tool: {
+    name: 'cancel_task',
+    description: 'Cancel a scheduled task.',
+    inputSchema: {
+      type: 'object' as const,
+      properties: {
+        taskId: { type: 'string', description: 'Task ID to cancel' },
+      },
+      required: ['taskId'],
+    },
+  },
+  async handler(args) {
+    const taskId = args.taskId as string;
+    if (!taskId) return err('taskId is required');
+
+    // Write as a system action — host will update inbound.db
+    writeMessageOut({
+      id: `sys-${Date.now()}-${Math.random().toString(36).slice(2, 8)}`,
+      kind: 'system',
+      content: JSON.stringify({ action: 'cancel_task', taskId }),
+    });
+
+    log(`cancel_task: ${taskId}`);
+    return ok(`Task cancellation requested: ${taskId}`);
+  },
+};
+
+export const pauseTask: McpToolDefinition = {
+  tool: {
+    name: 'pause_task',
+    description: 'Pause a scheduled task. It will not run until resumed.',
+    inputSchema: {
+      type: 'object' as const,
+      properties: {
+        taskId: { type: 'string', description: 'Task ID to pause' },
+      },
+      required: ['taskId'],
+    },
+  },
+  async handler(args) {
+    const taskId = args.taskId as string;
+    if (!taskId) return err('taskId is required');
+
+    writeMessageOut({
+      id: `sys-${Date.now()}-${Math.random().toString(36).slice(2, 8)}`,
+      kind: 'system',
+      content: JSON.stringify({ action: 'pause_task', taskId }),
+    });
+
+    log(`pause_task: ${taskId}`);
+    return ok(`Task pause requested: ${taskId}`);
+  },
+};
+
+export const resumeTask: McpToolDefinition = {
+  tool: {
+    name: 'resume_task',
+    description: 'Resume a paused task.',
+    inputSchema: {
+      type: 'object' as const,
+      properties: {
+        taskId: { type: 'string', description: 'Task ID to resume' },
+      },
+      required: ['taskId'],
+    },
+  },
+  async handler(args) {
+    const taskId = args.taskId as string;
+    if (!taskId) return err('taskId is required');
+
+    writeMessageOut({
+      id: `sys-${Date.now()}-${Math.random().toString(36).slice(2, 8)}`,
+      kind: 'system',
+      content: JSON.stringify({ action: 'resume_task', taskId }),
+    });
+
+    log(`resume_task: ${taskId}`);
+    return ok(`Task resume requested: ${taskId}`);
+  },
+};
+
+export const updateTask: McpToolDefinition = {
+  tool: {
+    name: 'update_task',
+    description:
+      'Update a scheduled task. Pass the series id from list_tasks. Any field omitted is left unchanged. Use this instead of cancel + reschedule when adjusting an existing task.',
+    inputSchema: {
+      type: 'object' as const,
+      properties: {
+        taskId: { type: 'string', description: 'Series id of the task to update (as shown by list_tasks)' },
+        prompt: { type: 'string', description: 'New task prompt (optional)' },
+        recurrence: {
+          type: 'string',
+          description: 'New cron expression (optional). Pass empty string to clear and make the task one-shot.',
+        },
+        processAfter: {
+          type: 'string',
+          description:
+            `New ISO 8601 timestamp for the next run (optional). Accepts either UTC (ending in "Z" / "+00:00") or a naive local timestamp interpreted in the user's timezone.`,
+        },
+        script: {
+          type: 'string',
+          description: 'New pre-agent script (optional). Pass empty string to clear.',
+        },
+      },
+      required: ['taskId'],
+    },
+  },
+  async handler(args) {
+    const taskId = args.taskId as string;
+    if (!taskId) return err('taskId is required');
+
+    const update: Record<string, unknown> = { taskId };
+    if (typeof args.prompt === 'string') update.prompt = args.prompt;
+    if (typeof args.processAfter === 'string') {
+      try {
+        const d = parseZonedToUtc(args.processAfter, TIMEZONE);
+        if (Number.isNaN(d.getTime())) return err(`invalid processAfter: ${args.processAfter}`);
+        update.processAfter = d.toISOString();
+      } catch {
+        return err(`invalid processAfter: ${args.processAfter}`);
+      }
+    }
+    // Empty string clears recurrence/script; undefined leaves them as-is.
+    if (typeof args.recurrence === 'string') update.recurrence = args.recurrence === '' ? null : args.recurrence;
+    if (typeof args.script === 'string') update.script = args.script === '' ? null : args.script;
+
+    if (Object.keys(update).length === 1) return err('at least one field to update is required');
+
+    writeMessageOut({
+      id: `sys-${Date.now()}-${Math.random().toString(36).slice(2, 8)}`,
+      kind: 'system',
+      content: JSON.stringify({ action: 'update_task', ...update }),
+    });
+
+    log(`update_task: ${taskId}`);
+    return ok(`Task update requested: ${taskId}`);
+  },
+};
+
+registerTools([scheduleTask, listTasks, updateTask, cancelTask, pauseTask, resumeTask]);

container/agent-runner/src/poll-loop.ts

@@ -1,6 +1,6 @@
 import { findByName, getAllDestinations, type DestinationEntry } from './destinations.js';
-import { getPendingMessages, markProcessing, markCompleted, markScriptSkipped, type MessageInRow } from './db/messages-in.js';
-import { hasIdenticalSend, writeMessageOut } from './db/messages-out.js';
+import { getPendingMessages, markProcessing, markCompleted, type MessageInRow } from './db/messages-in.js';
+import { writeMessageOut } from './db/messages-out.js';
 import { getInboundDb, touchHeartbeat, clearStaleProcessingAcks } from './db/connection.js';
 import {
   clearContinuation,
@@ -207,15 +207,15 @@ export async function runPollLoop(config: PollLoopConfig): Promise<void> {
     // Without the scheduling module, the marker block is empty, `keep`
     // falls back to `normalMessages`, and no gating happens.
     let keep: MessageInRow[] = normalMessages;
-    let skipped: Array<{ id: string; reason: string }> = [];
+    let skipped: string[] = [];
     // MODULE-HOOK:scheduling-pre-task:start
     const { applyPreTaskScripts } = await import('./scheduling/task-script.js');
     const preTask = await applyPreTaskScripts(normalMessages);
     keep = preTask.keep;
     skipped = preTask.skipped;
     if (skipped.length > 0) {
-      markScriptSkipped(skipped);
-      log(`Pre-task script skipped ${skipped.length} task(s): ${skipped.map((s) => s.id).join(', ')}`);
+      markCompleted(skipped);
+      log(`Pre-task script skipped ${skipped.length} task(s): ${skipped.join(', ')}`);
     }
     // MODULE-HOOK:scheduling-pre-task:end
 
@@ -238,7 +238,7 @@ export async function runPollLoop(config: PollLoopConfig): Promise<void> {
     });
 
     // Process the query while concurrently polling for new messages
-    const skippedSet = new Set(skipped.map((s) => s.id));
+    const skippedSet = new Set(skipped);
     const processingIds = ids.filter((id) => !commandIds.includes(id) && !skippedSet.has(id));
     // Publish the batch's in_reply_to so MCP tools (send_message, send_file)
     // can stamp it on outbound rows — needed for a2a return-path routing.
@@ -401,15 +401,15 @@ export async function processQuery(
         // its script gate and always wakes the agent, defeating the gate.
         // Mirrors the initial-batch hook above.
         let keep = newMessages;
-        let skipped: Array<{ id: string; reason: string }> = [];
+        let skipped: string[] = [];
         // MODULE-HOOK:scheduling-pre-task-followup:start
         const { applyPreTaskScripts } = await import('./scheduling/task-script.js');
         const preTask = await applyPreTaskScripts(newMessages);
         keep = preTask.keep;
         skipped = preTask.skipped;
         if (skipped.length > 0) {
-          markScriptSkipped(skipped);
-          log(`Pre-task script skipped ${skipped.length} follow-up task(s): ${skipped.map((s) => s.id).join(', ')}`);
+          markCompleted(skipped);
+          log(`Pre-task script skipped ${skipped.length} follow-up task(s): ${skipped.join(', ')}`);
         }
         // MODULE-HOOK:scheduling-pre-task-followup:end
 
@@ -650,15 +650,6 @@ function dispatchResultText(text: string, routing: RoutingContext): { sent: numb
 function sendToDestination(dest: DestinationEntry, body: string, routing: RoutingContext): void {
   const platformId = dest.type === 'channel' ? dest.platformId! : dest.agentGroupId!;
   const channelType = dest.type === 'channel' ? dest.channelType! : 'agent';
-  // Task fires: an explicitly-addressed final-text block is either the echo of
-  // an MCP send the agent already made this turn (drop it HERE, where the
-  // duplication originates) or the agent's only deliberate send (write it
-  // in_reply_to-null like the MCP path, or the host's task-fire suppression
-  // would discard it — zero delivery).
-  if (routing.taskFire && hasIdenticalSend(platformId, channelType, body)) {
-    log(`Dropping turn-final echo of an already-sent task message to ${dest.name}`);
-    return;
-  }
   // Resolve thread_id per-destination from the most recent inbound message
   // that came from this same channel+platform. In agent-shared sessions,
   // different destinations have different thread contexts — using a single
@@ -666,7 +657,7 @@ function sendToDestination(dest: DestinationEntry, body: string, routing: Routin
   const destRouting = resolveDestinationThread(channelType, platformId);
   writeMessageOut({
     id: generateId(),
-    in_reply_to: destRouting?.inReplyTo ?? (routing.taskFire ? null : routing.inReplyTo),
+    in_reply_to: destRouting?.inReplyTo ?? routing.inReplyTo,
     kind: 'chat',
     platform_id: platformId,
     channel_type: channelType,

container/agent-runner/src/providers/claude.ts

@@ -5,7 +5,6 @@ import path from 'path';
 import { query as sdkQuery, type HookCallback, type PreCompactHookInput } from '@anthropic-ai/claude-agent-sdk';
 
 import { clearContainerToolInFlight, setContainerToolInFlight } from '../db/connection.js';
-import { TIMEZONE, formatLocalStamp } from '../timezone.js';
 import { registerProvider } from './provider-registry.js';
 import type { AgentProvider, AgentQuery, McpServerConfig, ProviderEvent, ProviderOptions, QueryInput } from './types.js';
 
@@ -18,7 +17,7 @@ function log(msg: string): void {
 // Code's interactive UI and would hang here).
 //
 // - CronCreate / CronDelete / CronList / ScheduleWakeup: we have durable
-//   scheduling via `ncl tasks`.
+//   scheduling via mcp__nanoclaw__schedule_task.
 // - AskUserQuestion: SDK returns a placeholder instead of blocking on a
 //   real answer — we have mcp__nanoclaw__ask_user_question that persists
 //   the question and blocks on the real reply.
@@ -224,9 +223,7 @@ function archiveTranscriptFile(transcriptPath: string | undefined, sessionId: st
 
     const conversationsDir = process.env.NANOCLAW_CONVERSATIONS_DIR || '/workspace/agent/conversations';
     fs.mkdirSync(conversationsDir, { recursive: true });
-    // Local calendar date — the fallback `name` above already uses local
-    // hours, and the agent navigates conversations/ by these date prefixes.
-    const filename = `${formatLocalStamp(new Date(), TIMEZONE).slice(0, 10)}-${name}.md`;
+    const filename = `${new Date().toISOString().split('T')[0]}-${name}.md`;
     fs.writeFileSync(path.join(conversationsDir, filename), formatTranscriptMarkdown(messages, summary, assistantName));
     log(`Archived conversation to ${filename}`);
     return true;
@@ -452,7 +449,7 @@ export class ClaudeProvider implements AgentProvider {
           yield { type: 'result', text, isError: m.is_error === true };
         } else if (message.type === 'system' && (message as { subtype?: string }).subtype === 'api_retry') {
           yield { type: 'error', message: 'API retry', retryable: true };
-        } else if (message.type === 'rate_limit_event') {
+        } else if (message.type === 'system' && (message as { subtype?: string }).subtype === 'rate_limit_event') {
           yield { type: 'error', message: 'Rate limit', retryable: false, classification: 'quota' };
         } else if (message.type === 'system' && (message as { subtype?: string }).subtype === 'compact_boundary') {
           const meta = (message as { compact_metadata?: { pre_tokens?: number } }).compact_metadata;

container/agent-runner/src/scheduling/task-script.test.ts

@@ -1,72 +0,0 @@
-/**
- * Container leg of the script-failure backoff chain, tested at unit level so
- * the e2e suite doesn't need a live multi-sweep scenario for it:
- *
- *   script error → applyPreTaskScripts skips with reason 'error'
- *   → markScriptSkipped acks `script-skip:error` in outbound.db
- *   (gated → plain 'completed': the monitor working as designed).
- *
- * The host leg (ack → FAILED run → streak backoff) is pinned in
- * src/db/session-db.test.ts and src/modules/scheduling/recurrence.test.ts —
- * both sides pin the literal 'script-skip:error'; if either renames it, its
- * own test goes red.
- */
-import { describe, it, expect, beforeEach, afterEach } from 'bun:test';
-
-import { initTestSessionDb, closeSessionDb, getInboundDb, getOutboundDb } from '../db/connection.js';
-import { getPendingMessages, markScriptSkipped } from '../db/messages-in.js';
-import { applyPreTaskScripts } from './task-script.js';
-
-beforeEach(() => {
-  initTestSessionDb();
-});
-
-afterEach(() => {
-  closeSessionDb();
-});
-
-function insertTask(id: string, script: string) {
-  getInboundDb()
-    .prepare(
-      `INSERT INTO messages_in (id, kind, timestamp, status, trigger, content)
-       VALUES (?, 'task', datetime('now'), 'pending', 1, ?)`,
-    )
-    .run(id, JSON.stringify({ prompt: 'monitor', script }));
-}
-
-const ackStatus = (id: string): string | undefined =>
-  (getOutboundDb().prepare('SELECT status FROM processing_ack WHERE message_id = ?').get(id) as { status: string } | undefined)
-    ?.status;
-
-describe('script-skip ack chain (container leg)', () => {
-  it('an erroring script skips with reason "error" and acks script-skip:error', async () => {
-    insertTask('t-err', 'echo boom >&2; exit 1');
-    const { keep, skipped } = await applyPreTaskScripts(getPendingMessages());
-
-    expect(keep).toHaveLength(0);
-    expect(skipped).toEqual([{ id: 't-err', reason: 'error' }]);
-
-    markScriptSkipped(skipped);
-    expect(ackStatus('t-err')).toBe('script-skip:error');
-  });
-
-  it('a deliberate wakeAgent=false gate acks plain completed — never backs off', async () => {
-    insertTask('t-gated', 'echo \'{"wakeAgent": false}\'');
-    const { keep, skipped } = await applyPreTaskScripts(getPendingMessages());
-
-    expect(keep).toHaveLength(0);
-    expect(skipped).toEqual([{ id: 't-gated', reason: 'gated' }]);
-
-    markScriptSkipped(skipped);
-    expect(ackStatus('t-gated')).toBe('completed');
-  });
-
-  it('wakeAgent=true keeps the task and enriches the prompt with script data', async () => {
-    insertTask('t-wake', 'echo \'{"wakeAgent": true, "data": {"alerts": 2}}\'');
-    const { keep, skipped } = await applyPreTaskScripts(getPendingMessages());
-
-    expect(skipped).toHaveLength(0);
-    expect(keep).toHaveLength(1);
-    expect(JSON.parse(keep[0].content).scriptOutput).toEqual({ alerts: 2 });
-  });
-});

container/agent-runner/src/scheduling/task-script.ts

@@ -64,26 +64,21 @@ export async function runScript(script: string, taskId: string): Promise<ScriptR
   });
 }
 
-/** Why a script gated its task: deliberate wakeAgent=false vs a broken script. */
-export type ScriptSkipReason = 'gated' | 'error';
-
 export interface TaskScriptOutcome {
   keep: MessageInRow[];
-  skipped: Array<{ id: string; reason: ScriptSkipReason }>;
+  skipped: string[];
 }
 
 /**
  * Run pre-task scripts for any task messages that carry one, serially.
- * - Errors / missing output / wakeAgent=false → task id added to `skipped`,
- *   with the reason. The caller acks these as script-skips (not plain
- *   completions) so the host can count consecutive failures and back off.
+ * - Errors / missing output / wakeAgent=false → task id added to `skipped`.
  * - wakeAgent=true → content JSON is mutated to carry `scriptOutput`, so the
  *   formatter renders it into the prompt.
  * Non-task messages and tasks without scripts pass through unchanged.
  */
 export async function applyPreTaskScripts(messages: MessageInRow[]): Promise<TaskScriptOutcome> {
   const keep: MessageInRow[] = [];
-  const skipped: Array<{ id: string; reason: ScriptSkipReason }> = [];
+  const skipped: string[] = [];
 
   for (const msg of messages) {
     if (msg.kind !== 'task') {
@@ -111,9 +106,9 @@ export async function applyPreTaskScripts(messages: MessageInRow[]): Promise<Tas
     touchHeartbeat();
 
     if (!result || !result.wakeAgent) {
-      const reason: ScriptSkipReason = result ? 'gated' : 'error';
-      log(`task ${msg.id} skipped: ${reason === 'gated' ? 'wakeAgent=false' : 'script error/no output'}`);
-      skipped.push({ id: msg.id, reason });
+      const reason = result ? 'wakeAgent=false' : 'script error/no output';
+      log(`task ${msg.id} skipped: ${reason}`);
+      skipped.push(msg.id);
       continue;
     }
 

container/agent-runner/src/timezone.ts

@@ -48,22 +48,6 @@ export function formatLocalTime(utcIso: string, timezone: string): string {
   });
 }
 
-/**
- * Compact sortable local stamp for log lines: "YYYY-MM-DD HH:mm" in `timezone`.
- * (sv-SE is the one locale whose default rendering is this exact shape.)
- */
-export function formatLocalStamp(date: Date, timezone: string): string {
-  return date.toLocaleString('sv-SE', {
-    timeZone: resolveTimezone(timezone),
-    year: 'numeric',
-    month: '2-digit',
-    day: '2-digit',
-    hour: '2-digit',
-    minute: '2-digit',
-    hour12: false,
-  });
-}
-
 function resolveContainerTimezone(): string {
   const candidates = [process.env.TZ, Intl.DateTimeFormat().resolvedOptions().timeZone];
   for (const tz of candidates) {

container/skills/agent-browser/SKILL.md

@@ -92,41 +92,6 @@ agent-browser wait --url "**/dashboard"    # Wait for URL pattern
 agent-browser wait --load networkidle      # Wait for network idle
 ```
 
-### Waiting for a custom condition — ALWAYS bound it
-
-Prefer the built-in `wait` subcommands above. Only fall back to `eval`-polling
-when you must wait on a custom JS condition (e.g. a spinner disappearing or a
-"Send" button re-enabling in a chat UI).
-
-**Never write an unbounded wait loop.** A bare `until … do sleep; done` that
-polls a page condition will loop *forever* if the condition never becomes true
-(page failed to load, selector changed, network stalled). That does not just
-fail the command — it wedges the entire agent turn: the runner keeps the model
-stream open, later messages get silently swallowed, and the container can hang
-for hours without the host's stuck-detection firing.
-
-Always cap the wait with BOTH a wall-clock `timeout` and a max-attempts counter,
-and always exit the loop (never leave a `sleep` loop as the last thing running):
-
-```bash
-# Bounded wait: succeeds when the condition is met, gives up after ~90s.
-timeout 90 bash -c '
-  for i in $(seq 1 30); do
-    if agent-browser eval "document.querySelector(\".loading\") === null" 2>/dev/null | grep -q true; then
-      echo READY; exit 0
-    fi
-    sleep 3
-  done
-  echo TIMEOUT; exit 1
-'
-# Check the exit status / output: on TIMEOUT, snapshot the page and decide —
-# do NOT re-enter another unbounded wait.
-```
-
-If the wait times out, treat it as a real failure: take a `snapshot -i` or
-`screenshot` to see the actual page state, report what you found, and move on.
-Retrying the same unbounded wait is what causes the hang.
-
 ### Semantic locators (alternative to refs)
 
 ```bash

container/skills/slack-formatting/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: slack-formatting
+description: Format messages for Slack using mrkdwn syntax. Use when responding to Slack channels (folder starts with "slack_" or JID contains slack identifiers).
+---
+
+# Slack Message Formatting (mrkdwn)
+
+When responding to Slack channels, use Slack's mrkdwn syntax instead of standard Markdown.
+
+## How to detect Slack context
+
+Check your group folder name or workspace path:
+- Folder starts with `slack_` (e.g., `slack_engineering`, `slack_general`)
+- Or check `/workspace/group/` path for `slack_` prefix
+
+## Formatting reference
+
+### Text styles
+
+| Style | Syntax | Example |
+|-------|--------|---------|
+| Bold | `*text*` | *bold text* |
+| Italic | `_text_` | _italic text_ |
+| Strikethrough | `~text~` | ~strikethrough~ |
+| Code (inline) | `` `code` `` | `inline code` |
+| Code block | ` ```code``` ` | Multi-line code |
+
+### Links and mentions
+
+```
+<https://example.com|Link text>     # Named link
+<https://example.com>                # Auto-linked URL
+<@U1234567890>                       # Mention user by ID
+<#C1234567890>                       # Mention channel by ID
+<!here>                              # @here
+<!channel>                           # @channel
+```
+
+### Lists
+
+Slack supports simple bullet lists but NOT numbered lists:
+
+```
+• First item
+• Second item
+• Third item
+```
+
+Use `•` (bullet character) or `- ` or `* ` for bullets.
+
+### Block quotes
+
+```
+> This is a block quote
+> It can span multiple lines
+```
+
+### Emoji
+
+Use standard emoji shortcodes: `:white_check_mark:`, `:x:`, `:rocket:`, `:tada:`
+
+## What NOT to use
+
+- **NO** `##` headings (use `*Bold text*` for headers instead)
+- **NO** `**double asterisks**` for bold (use `*single asterisks*`)
+- **NO** `[text](url)` links (use `<url|text>` instead)
+- **NO** `1.` numbered lists (use bullets with numbers: `• 1. First`)
+- **NO** tables (use code blocks or plain text alignment)
+- **NO** `---` horizontal rules
+
+## Example message
+
+```
+*Daily Standup Summary*
+
+_March 21, 2026_
+
+• *Completed:* Fixed authentication bug in login flow
+• *In Progress:* Building new dashboard widgets
+• *Blocked:* Waiting on API access from DevOps
+
+> Next sync: Monday 10am
+
+:white_check_mark: All tests passing | <https://ci.example.com/builds/123|View Build>
+```
+
+## Quick rules
+
+1. Use `*bold*` not `**bold**`
+2. Use `<url|text>` not `[text](url)`
+3. Use `•` bullets, avoid numbered lists
+4. Use `:emoji:` shortcodes
+5. Quote blocks with `>`
+6. Skip headings — use bold text instead

container/skills/whatsapp-formatting/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: whatsapp-formatting
+description: Format messages for WhatsApp, including mentions that render as real WhatsApp tags. Use when responding in a WhatsApp conversation (platform_id / chatJid ends with @s.whatsapp.net or @g.us).
+---
+
+# WhatsApp Message Formatting
+
+WhatsApp uses its own lightweight markup and a phone-number-based mention syntax. The host's WhatsApp adapter (Baileys) handles markdown conversion automatically, but **mentions are only protocol-level mentions if you use the right syntax** — otherwise they render as plain text and don't notify the recipient.
+
+## How to detect WhatsApp context
+
+You're in a WhatsApp conversation when any of these are true:
+- The chat JID / platform id ends with `@s.whatsapp.net` (1-on-1 DM)
+- The chat JID / platform id ends with `@g.us` (group)
+- Your inbound message metadata has `chatJid` matching the above
+
+## Mentions — the important part
+
+To tag a user so their name appears **bold and clickable** in WhatsApp and they get a push notification, write the `@` followed by their phone number digits (no `+`, no spaces, no display name):
+
+```
+@15551234567 can you confirm?
+```
+
+The adapter scans your outgoing text for `@<digits>` (5–15 digits, optional leading `+` is stripped) and tells WhatsApp to render them as real mention tags.
+
+**The sender's phone JID is always in your inbound message metadata.** When a user writes to you, inbound `content.sender` looks like `15551234567@s.whatsapp.net`. The part before the `@` is exactly what you put after `@` when tagging them back.
+
+### Wrong vs right
+
+| You write | What recipients see |
+|-----------|---------------------|
+| `@Adam can you...` | Plain text `@Adam`. No tag, no notification. |
+| `@15551234567 can you...` | Bold/blue **@Adam** (or whatever name they're saved as), notification fires. |
+| `@+15551234567 ...` | Same as above — adapter strips the `+`. |
+
+### Picking who to tag
+
+- In a DM, there's no real need to tag the recipient (they already see every message), but tagging still works if you want emphasis.
+- In a group, look at the `participants` / inbound `content.sender` to find the JID of the person you mean. Don't guess from display names — pushNames can collide and are not reliable.
+- If you don't know the JID, just refer to the person by name in plain prose. Don't write `@<name>` — it won't tag and it will look like a tag that failed.
+
+## Text styles
+
+WhatsApp uses single-character delimiters, *not* doubled like standard Markdown.
+
+| Style | Syntax | Renders as |
+|-------|--------|------------|
+| Bold | `*bold*` | **bold** |
+| Italic | `_italic_` | *italic* |
+| Strikethrough | `~strike~` | ~strike~ |
+| Monospace | `` `code` `` | `code` |
+| Block monospace | ```` ```block``` ```` | preformatted block |
+
+The adapter converts standard Markdown (`**bold**`, `[link](url)`, `# heading`) to the WhatsApp-native form automatically, so you don't have to think about it — but be aware that single asterisks become italics, not bold.
+
+## What not to do
+
+- Don't write `<@U123>` (that's Slack), `<@!123>` (Discord), or any other channel's mention syntax.
+- Don't paste a full JID like `@15551234567@s.whatsapp.net` in the text — only the digits before the JID's `@` go after your `@`.
+- Don't try to tag display names. WhatsApp has no display-name-based mention API.

container/skills/whatsapp-formatting/instructions.md

@@ -0,0 +1,19 @@
+## WhatsApp mentions — always use phone digits
+
+When you are replying in a WhatsApp conversation (the inbound message's `chatJid` ends with `@s.whatsapp.net` for a DM or `@g.us` for a group), and you want to tag a person so their name appears **bold and clickable** with a push notification, write `@` followed by their phone-number digits — never the display name.
+
+**The sender's phone JID is in your inbound message metadata** at `content.sender` (e.g. `15551234567@s.whatsapp.net`). The part before the `@` is exactly what you put after `@` when tagging them.
+
+| You write | What recipients see |
+|-----------|---------------------|
+| `@Adam, can you...` | Plain text. No tag, no notification. |
+| `@15551234567, can you...` | Bold/blue **@Adam** (whatever name they're saved as), notification fires. |
+| `@+15551234567 ...` | Same as above — the adapter strips the `+` automatically. |
+
+The host adapter scans your outbound text for `@<5–15 digits>` (with optional leading `+`) and tells WhatsApp to render those as real mention tags. If the digits aren't in the text, the tag doesn't render — no exceptions.
+
+### In groups
+
+Tag the person you're addressing using their JID from inbound metadata (look at the most recent message from them). Don't guess — pushNames collide and aren't reliable.
+
+If you don't know someone's JID, refer to them by name in plain prose. Do not write `@<displayname>` hoping it works.

docs/REQUIREMENTS.md

@@ -20,7 +20,7 @@ The entire codebase should be something you can read and understand. One Node.js
 
 ### Security Through True Isolation
 
-Instead of application-level permission systems trying to prevent agents from accessing things, agents run in actual Linux containers. The isolation is at the OS level. Agents can only see what's explicitly mounted. Bash access is safe because commands run inside the container, not on your host.
+Instead of application-level permission systems trying to prevent agents from accessing things, agents run in actual Linux containers. The isolation is at the OS level. Agents can only see what's explicitly mounted. Bash access is safe because commands run inside the container, not on your Mac.
 
 ### Built for the Individual User
 
@@ -47,23 +47,23 @@ When people contribute, they shouldn't add "Telegram support alongside WhatsApp.
 Skills we'd like to see contributed:
 
 ### Communication Channels
+- `/add-signal` - Add Signal as a channel
+- `/add-matrix` - Add Matrix integration
 
-None currently — Signal and Matrix have since shipped as skills.
-
-> **Note:** Telegram, Slack, Discord, Gmail, Signal, and Matrix skills already exist. See the [skills documentation](https://docs.nanoclaw.dev/integrations/skills-system) for the full list.
+> **Note:** Telegram, Slack, Discord, Gmail, and Apple Container skills already exist. See the [skills documentation](https://docs.nanoclaw.dev/integrations/skills-system) for the full list.
 
 ---
 
 ## Vision
 
-A personal AI assistant accessible via messaging, with minimal custom code.
+A personal Claude assistant accessible via messaging, with minimal custom code.
 
 **Core components:**
 - **Claude Agent SDK** as the core agent
-- **Containers** for isolated agent execution (Docker)
+- **Containers** for isolated agent execution (Linux VMs)
 - **Multi-channel messaging** (WhatsApp, Telegram, Discord, Slack, Gmail) — add exactly the channels you need
 - **Persistent memory** per conversation and globally
-- **Scheduled tasks** executed by the agent, which can message back
+- **Scheduled tasks** that run Claude and can message back
 - **Web access** for search and browsing
 - **Browser automation** via agent-browser
 
@@ -93,14 +93,14 @@ A personal AI assistant accessible via messaging, with minimal custom code.
 - Sessions auto-compact when context gets too long, preserving critical information
 
 ### Container Isolation
-- All agents run inside Docker containers
+- All agents run inside containers (lightweight Linux VMs)
 - Each agent invocation spawns a container with mounted directories
 - Containers provide filesystem isolation - agents can only see mounted paths
 - Bash access is safe because commands run inside the container, not on the host
 - Browser automation via agent-browser with Chromium in the container
 
 ### Scheduled Tasks
-- Users can ask the agent to schedule recurring or one-time tasks from any group
+- Users can ask Claude to schedule recurring or one-time tasks from any group
 - Tasks run as full agents in the context of the group that created them
 - Tasks have access to all tools including Bash (safe in container)
 - Tasks can optionally send messages to their group via `send_message` tool, or complete silently
@@ -134,11 +134,11 @@ A personal AI assistant accessible via messaging, with minimal custom code.
 
 ### Scheduler
 - Built-in scheduler runs on the host, spawns containers for task execution
-- `ncl tasks` provides scheduling commands
-- Commands: `list`, `get`, `create`, `update`, `cancel`, `pause`, `resume`, `delete`, `run`, `append-log`
+- Custom `nanoclaw` MCP server (inside container) provides scheduling tools
+- Tools: `schedule_task`, `list_tasks`, `pause_task`, `resume_task`, `cancel_task`, `send_message`
 - Tasks stored in SQLite with run history
 - Scheduler loop checks for due tasks every minute
-- Tasks execute in the agent group's system session
+- Tasks execute Claude Agent SDK in containerized group context
 
 ### Web Access
 - Built-in WebSearch and WebFetch tools

docs/SECURITY.md

@@ -169,6 +169,61 @@ pip, curl, node/bun with the proxy env) are unaffected. Any workflow that relies
 on a **non-proxy-aware** tool reaching the internet directly will fail by design.
 Lockdown is **off by default**; opt in with `NANOCLAW_EGRESS_LOCKDOWN=true`.
 
+### 6. Local Audit Log (Opt-In)
+
+Every `ncl` command (both transports — host socket and container — including
+denials) and every approval the host routes (request, decision, and terminal
+outcome; covering CLI gates, self-mod, a2a message gates, agent creation, the
+permissions sender/channel cards, and OneCLI credential holds) is recorded as
+one canonical, SIEM-shaped JSON event.
+
+- **Off by default.** Nothing is persisted until an operator sets
+  `AUDIT_ENABLED=true`; when disabled, the emitter no-ops and `data/audit/` is
+  never created. `ncl audit list` on a disabled box errors instead of returning
+  an empty list.
+- **Store:** append-only NDJSON day-files under `data/audit/<UTC-day>.ndjson`,
+  written only by the host process. Retention is a hard delete — whole
+  day-files past the horizon are unlinked at boot and once daily in the host
+  sweep.
+- **Fail-open + loud:** a failed append is logged and the action proceeds (a
+  full disk must not brick recovery commands). At boot, an enabled box refuses
+  to start if `data/audit/` isn't writable.
+- **No secrets, no message bodies:** a recursive key mask
+  (`token|secret|key|password|credential|auth|bearer`) redacts details at the
+  single emit point, values are truncated to ~2 KB, and message-bearing events
+  (a2a gates, OneCLI body previews) record shape only — `body_chars` and
+  attachment names, never content.
+- **Scope:** `ncl audit list` is available to host callers and global-scope
+  agents only. `audit` is not on the group-scope allowlist, so confined agents
+  are refused before any handler runs.
+
+| Env | Default | Meaning |
+| --- | --- | --- |
+| `AUDIT_ENABLED` | `false` | Set `true` to record audit events. |
+| `AUDIT_RETENTION_DAYS` | `90` | Days before day-files are unlinked; `0` = keep forever. Read only when enabled. |
+
+Read back with `ncl audit list --actor … --action … --resource … --outcome …
+--since 7d --correlation … --limit 100`; `--format ndjson` streams the stored
+lines for SIEM export. Event fields are chosen to project losslessly onto
+OCSF and Elastic ECS; forwarding is a mapping exercise, deferred until a
+forwarder exists.
+
+**Integration surfaces** (no push forwarder ships in core — credentials and
+transport for external systems never live here):
+
+1. **Tail the store** — any external agent (Vector, Filebeat, Fluent Bit, a
+   custom daemon) tails `data/audit/*.ndjson`; the format is stable and
+   `schema_version`-stamped.
+2. **Pull via the CLI** — poll `ncl audit list --format ndjson --since …` and
+   dedupe on `event_id`.
+3. **In-process post-write hooks** — a module (in-tree or skill-installed)
+   calls `registerAuditHook({ name, onEvent, init?, maintain?, shutdown? })`
+   from `src/audit/`. Hooks fire only **after** an event is durably appended
+   to the local day-file, so anything exported is guaranteed to exist in the
+   source of truth; a hook that misses events catches up by reading the
+   day-files (at-least-once). Hook failures are isolated and logged — they
+   never affect the log, other hooks, or the audited action.
+
 ## Resource Limits
 
 Per-container CPU and memory caps are **opt-in and unset by default** — a runaway

docs/SPEC.md

@@ -579,7 +579,12 @@ NanoClaw has a built-in scheduler that runs tasks as full agents in their group'
 ```
 User: @Andy remind me every Monday at 9am to review the weekly metrics
 
-Claude: [runs ncl tasks create --prompt "Send a reminder to review weekly metrics. Be encouraging!" --process-after "2024-02-05T09:00:00" --recurrence "0 9 * * 1"]
+Claude: [calls mcp__nanoclaw__schedule_task]
+        {
+          "prompt": "Send a reminder to review weekly metrics. Be encouraging!",
+          "schedule_type": "cron",
+          "schedule_value": "0 9 * * 1"
+        }
 
 Claude: Done! I'll remind you every Monday at 9am.
 ```
@@ -589,7 +594,12 @@ Claude: Done! I'll remind you every Monday at 9am.
 ```
 User: @Andy at 5pm today, send me a summary of today's emails
 
-Claude: [runs ncl tasks create --prompt "Search for today's emails, summarize the important ones, and send the summary to the group." --process-after "2024-01-31T17:00:00"]
+Claude: [calls mcp__nanoclaw__schedule_task]
+        {
+          "prompt": "Search for today's emails, summarize the important ones, and send the summary to the group.",
+          "schedule_type": "once",
+          "schedule_value": "2024-01-31T17:00:00Z"
+        }
 ```
 
 ### Managing Tasks
@@ -610,11 +620,18 @@ From main channel:
 
 ### NanoClaw MCP (built-in)
 
-The `nanoclaw` MCP server is created dynamically per agent call with the current group's context. Scheduled task management lives in `ncl tasks`, not MCP.
+The `nanoclaw` MCP server is created dynamically per agent call with the current group's context.
 
 **Available Tools:**
 | Tool | Purpose |
 |------|---------|
+| `schedule_task` | Schedule a recurring or one-time task |
+| `list_tasks` | Show tasks (group's tasks, or all if main) |
+| `get_task` | Get task details and run history |
+| `update_task` | Modify task prompt or schedule |
+| `pause_task` | Pause a task |
+| `resume_task` | Resume a paused task |
+| `cancel_task` | Delete a task |
 | `send_message` | Send a message to the group via its channel |
 
 ---

docs/agent-runner-details.md

@@ -14,62 +14,37 @@ The boundary: the agent-runner decides **what** to send and **what to do** with
 
 ## AgentProvider Interface
 
-Provider-wide settings (MCP servers, env, additional directories, model, effort,
-assistant name) are passed to the provider **constructor** via `ProviderOptions`, not
-per query. `QueryInput` carries only what changes turn to turn: the prompt, the
-continuation token to resume, the working directory, and system context to inject.
-
 ```typescript
 interface AgentProvider {
-  /** True if the SDK handles slash commands natively and wants them passed
-   *  through raw. When false, the poll-loop formats them like any chat message. */
-  readonly supportsNativeSlashCommands: boolean;
-
-  /** Opt-in: scaffold a persistent memory/ tree at boot. Providers with native
-   *  memory (Claude's CLAUDE.local.md) omit it. Never gated on a provider name. */
-  readonly usesMemoryScaffold?: boolean;
-
-  /** Optional. Called after each completed exchange so providers whose harness
-   *  keeps no on-disk transcript can persist it themselves. Claude (the SDK
-   *  writes its own .jsonl) omits this. */
-  onExchangeComplete?(exchange: ProviderExchange): void;
-
   /** Start a new query. Returns a handle for streaming input and output. */
   query(input: QueryInput): AgentQuery;
-
-  /** True if the error means the stored continuation is invalid (missing
-   *  transcript, unknown session) and should be cleared. */
-  isSessionInvalid(err: unknown): boolean;
-
-  /** Optional pre-resume maintenance: given the stored continuation, return a
-   *  reason string to drop it and start fresh (e.g. transcript too large/old to
-   *  cold-resume before the host idle ceiling), or null to keep resuming. */
-  maybeRotateContinuation?(continuation: string, cwd: string): string | null;
-}
-
-interface ProviderOptions {
-  assistantName?: string;
-  mcpServers?: Record<string, McpServerConfig>;
-  env?: Record<string, string | undefined>;
-  additionalDirectories?: string[];
-  model?: string;   // alias (sonnet/opus/haiku) or full model ID
-  effort?: string;  // low | medium | high | xhigh | max
 }
 
 interface QueryInput {
-  /** Initial prompt, already formatted by the agent-runner into a string. */
-  prompt: string;
+  /** Initial prompt (already formatted by agent-runner).
+   *  String for text-only. ContentBlock[] for multimodal (images, PDFs, audio). */
+  prompt: string | ContentBlock[];
 
-  /** Opaque continuation token from a previous query. The provider decides
-   *  what it means (session ID, thread ID, or nothing). */
-  continuation?: string;
+  /** Session ID to resume, if any */
+  sessionId?: string;
 
-  /** Working directory inside the container. */
+  /** Resume from a specific point in the session (provider-specific, may be ignored) */
+  resumeAt?: string;
+
+  /** Working directory inside the container */
   cwd: string;
 
-  /** System context to inject; the provider translates it into whatever its
-   *  SDK expects (preset append, full system prompt, per-turn injection). */
-  systemContext?: { instructions?: string };
+  /** MCP server configurations (normalized format — provider translates) */
+  mcpServers: Record<string, McpServerConfig>;
+
+  /** System prompt / developer instructions */
+  systemPrompt?: string;
+
+  /** Environment variables for the SDK process */
+  env: Record<string, string | undefined>;
+
+  /** Additional directories the agent can access */
+  additionalDirectories?: string[];
 }
 
 interface McpServerConfig {
@@ -79,42 +54,40 @@ interface McpServerConfig {
 }
 
 interface AgentQuery {
-  /** Push a follow-up message into the active query. */
+  /** Push a follow-up message into the active query */
   push(message: string): void;
 
-  /** Signal that no more input will be sent. */
+  /** Signal that no more input will be sent */
   end(): void;
 
-  /** Output event stream. */
+  /** Output event stream */
   events: AsyncIterable<ProviderEvent>;
 
-  /** Force-stop the query (e.g., container shutting down). */
+  /** Force-stop the query (e.g., container shutting down) */
   abort(): void;
 }
 
 type ProviderEvent =
-  | { type: 'init'; continuation: string }
-  | { type: 'result'; text: string | null; isError?: boolean }
+  | { type: 'init'; sessionId: string }
+  | { type: 'result'; text: string | null }
   | { type: 'error'; message: string; retryable: boolean; classification?: string }
-  | { type: 'progress'; message: string }
-  | { type: 'activity' };
+  | { type: 'progress'; message: string };
 ```
 
 ### What the interface does NOT include
 
 - **Message formatting** — the agent-runner formats messages before passing to the provider. The provider receives a ready-to-send prompt string.
-- **Hooks** — Claude-specific. The Claude provider registers hooks internally (PreToolUse, PostToolUse, PreCompact). Other providers don't need them.
-- **Tool allowlists** — Claude uses `allowedTools` + `disallowedTools`. Other SDKs use their own equivalents. Each provider configures this internally.
-- **Session persistence** — the agent-runner stores one opaque `continuation` token per provider (see [Session Resume](#session-resume)) and passes it back as `QueryInput.continuation`. What it means is provider-private; Claude persists its own `.jsonl` transcript on disk keyed by the continuation (session ID).
+- **Hooks** — Claude-specific. The Claude provider registers hooks internally (PreCompact, PreToolUse, etc.). Other providers don't need them.
+- **Tool allowlists** — Claude uses `allowedTools`. Codex uses `approvalPolicy`. OpenCode uses `permission`. Each provider configures this internally based on the same intent: "allow everything, no prompting."
+- **Session persistence** — Claude persists sessions to disk automatically. Codex and OpenCode manage their own session state. The agent-runner doesn't control this — it just passes `sessionId` and `resumeAt`.
 - **Sandbox configuration** — provider-specific. Each provider configures its own sandbox internally.
 
 ### Provider event semantics
 
-- **`init`** — emitted once per query when the provider establishes or resumes a session. The agent-runner captures `continuation` and persists it for future resume.
-- **`result`** — emitted when the agent produces a complete response. May be emitted multiple times per query (e.g., Claude's multi-turn with subagents). `isError` is set when the SDK flagged the turn as an error (e.g. a non-retryable billing error) so the poll-loop still surfaces the text instead of dropping it. The agent-runner writes each result to messages_out.
-- **`error`** — emitted on failure. `retryable` indicates whether the agent-runner should retry. `classification` is optional detail (e.g., 'quota').
+- **`init`** — emitted once per query when the provider establishes or resumes a session. The agent-runner captures `sessionId` for future resume.
+- **`result`** — emitted when the agent produces a complete response. May be emitted multiple times per query (e.g., Claude's multi-turn with subagents). The agent-runner writes each result to messages_out.
+- **`error`** — emitted on failure. `retryable` indicates whether the agent-runner should retry. `classification` is optional detail (e.g., 'quota', 'auth', 'transport').
 - **`progress`** — optional, for logging. The agent-runner logs these but doesn't act on them.
-- **`activity`** — a liveness signal. Providers MUST yield it on every underlying SDK event (tool call, thinking, partial message) so the poll-loop's idle timer stays honest during long tool runs.
 
 ## Provider Implementations
 
@@ -124,82 +97,58 @@ Only the `claude` provider ships in trunk. The Codex and OpenCode sections below
 
 Wraps `@anthropic-ai/claude-agent-sdk`'s `query()`.
 
-The provider takes its settings (`mcpServers`, `env`, `additionalDirectories`,
-`model`, `effort`, `assistantName`) in its constructor via `ProviderOptions`; `query()`
-only reads the per-turn `QueryInput`.
-
 ```typescript
 class ClaudeProvider implements AgentProvider {
-  readonly supportsNativeSlashCommands = true;
-  // ...constructor stores options.mcpServers, .env, .additionalDirectories,
-  //    .model, .effort, .assistantName...
-
   query(input: QueryInput): AgentQuery {
     const stream = new MessageStream();  // AsyncIterable<SDKUserMessage>
     stream.push(input.prompt);
 
-    const sdkResult = sdkQuery({
+    const sdkQuery = query({
       prompt: stream,
       options: {
         cwd: input.cwd,
-        additionalDirectories: this.additionalDirectories,
-        resume: input.continuation,
-        pathToClaudeCodeExecutable: '/pnpm/claude',
-        systemPrompt: input.systemContext?.instructions
-          ? { type: 'preset', preset: 'claude_code', append: input.systemContext.instructions }
+        resume: input.sessionId,
+        resumeSessionAt: input.resumeAt,
+        systemPrompt: input.systemPrompt
+          ? { type: 'preset', preset: 'claude_code', append: input.systemPrompt }
           : undefined,
-        // Base tools plus one `mcp__<server>__*` pattern per registered MCP
-        // server — without the explicit MCP patterns the SDK's allowedTools
-        // filter silently drops every MCP namespace.
-        allowedTools: [...TOOL_ALLOWLIST, ...Object.keys(this.mcpServers).map(mcpAllowPattern)],
-        disallowedTools: SDK_DISALLOWED_TOOLS,
-        env: this.env,
-        model: this.model,
-        effort: this.effort,
+        mcpServers: input.mcpServers,  // already the right shape
+        additionalDirectories: input.additionalDirectories,
+        env: input.env,
+        allowedTools: NANOCLAW_TOOL_ALLOWLIST,
         permissionMode: 'bypassPermissions',
         allowDangerouslySkipPermissions: true,
-        settingSources: ['project', 'user', 'local'],
-        mcpServers: this.mcpServers,
         hooks: {
-          PreToolUse: [{ hooks: [preToolUseHook] }],
-          PostToolUse: [{ hooks: [postToolUseHook] }],
-          PostToolUseFailure: [{ hooks: [postToolUseHook] }],
-          PreCompact: [{ hooks: [createPreCompactHook(this.assistantName)] }],
+          PreCompact: [{ hooks: [preCompactHook] }],
+          PreToolUse: [{ matcher: 'Bash', hooks: [sanitizeBashHook] }],
         },
       },
     });
 
-    let aborted = false;
     return {
       push: (msg) => stream.push(msg),
       end: () => stream.end(),
-      // Abort doesn't call into the SDK — it flips a flag the event generator
-      // checks and ends the input stream so the query drains and stops.
-      abort: () => { aborted = true; stream.end(); },
-      events: translateEvents(sdkResult, () => aborted),
+      abort: () => sdkQuery.close(),
+      events: translateClaudeEvents(sdkQuery),
     };
   }
 }
 ```
 
-`translateEvents` is an async generator that yields `{ type: 'activity' }` for **every**
-SDK message (so the idle timer stays honest) and maps recognized messages to `ProviderEvent`:
-- `system`/`init` → `{ type: 'init', continuation: session_id }`
-- `result` → `{ type: 'result', text, isError }` — `text` is `result.result`, or the joined `result.errors[]` on error subtypes (billing/quota), so the notice still reaches the user
-- `system`/`api_retry` → `{ type: 'error', retryable: true }`
-- `system`/`rate_limit_event` → `{ type: 'error', retryable: false, classification: 'quota' }`
-- `system`/`compact_boundary` → `{ type: 'result', text: 'Context compacted…' }`
-- `system`/`task_notification` → `{ type: 'progress', message }`
-- when the `aborted` flag is set → the generator returns immediately
+`translateClaudeEvents` is an async generator that maps SDK messages to `ProviderEvent`:
+- `message.type === 'system' && message.subtype === 'init'` → `{ type: 'init', sessionId }`
+- `message.type === 'result'` → `{ type: 'result', text }`
+- `message.type === 'system' && message.subtype === 'api_retry'` → `{ type: 'error', retryable: true }`
+- `message.type === 'system' && message.subtype === 'rate_limit_event'` → `{ type: 'error', retryable: false, classification: 'quota' }`
+- `message.type === 'system' && message.subtype === 'task_notification'` → `{ type: 'progress', message }`
+- Everything else → logged, not emitted
 
-**Claude-specific behavior inside the provider:**
-- `MessageStream` for async iterable input (push-based follow-ups)
-- Resume via the SDK `resume` option keyed on the stored `continuation` (the SDK session ID) — no separate resume-at cursor
-- `TOOL_ALLOWLIST` (Bash, Read, Write, Edit, Glob, Grep, WebSearch, WebFetch, Task, Skill, …) extended at the call site with a `mcp__<server>__*` pattern per registered MCP server; `SDK_DISALLOWED_TOOLS` blocks SDK builtins that collide with NanoClaw's own scheduling/interaction model (CronCreate/Delete/List, ScheduleWakeup, AskUserQuestion, Enter/ExitPlanMode, Enter/ExitWorktree)
-- **PreToolUse hook** records the current tool + its declared timeout to `container_state` (so the host sweep widens its stuck tolerance while a long Bash runs) and, as defense-in-depth, blocks any `SDK_DISALLOWED_TOOLS` call that slips through. It does **not** sanitize bash env vars — there is no such hook.
-- **PostToolUse / PostToolUseFailure** hooks clear the in-flight tool
-- **PreCompact** hook archives the transcript to `conversations/` before compaction
-- `maybeRotateContinuation` drops an oversized/aged transcript (default caps 12 MB / 14 days, both operator-overridable) so a cold container isn't killed reloading days of `.jsonl` before the host idle ceiling; `isSessionInvalid` clears a continuation whose transcript is gone
+**Claude-specific features preserved inside the provider:**
+- `MessageStream` for async iterable input (push-based)
+- `resumeSessionAt` for resume at specific message UUID
+- PreCompact hook for transcript archiving
+- PreToolUse hook for sanitizing bash env vars
+- Full tool allowlist
 - `additionalDirectories` for multi-directory access
 
 ### Codex Provider
@@ -210,8 +159,8 @@ Wraps `@openai/codex-sdk`.
 class CodexProvider implements AgentProvider {
   query(input: QueryInput): AgentQuery {
     const codex = new Codex(this.buildOptions(input));
-    const thread = input.continuation
-      ? codex.resumeThread(input.continuation, this.threadOptions(input))
+    const thread = input.sessionId
+      ? codex.resumeThread(input.sessionId, this.threadOptions(input))
       : codex.startThread(this.threadOptions(input));
 
     const abortController = new AbortController();
@@ -239,13 +188,13 @@ class CodexProvider implements AgentProvider {
           signal: abortController.signal,
         });
 
-        let continuation: string | undefined;
+        let sessionId: string | undefined;
         let resultText = '';
 
         for await (const event of streamed.events) {
           if (event.type === 'thread.started') {
-            continuation = event.thread_id;
-            yield { type: 'init', continuation };
+            sessionId = event.thread_id;
+            yield { type: 'init', sessionId };
           }
           if (event.type === 'item.completed' && event.item.type === 'agent_message') {
             resultText = event.item.text || resultText;
@@ -315,7 +264,7 @@ class OpenCodeProvider implements AgentProvider {
 
   private async *run(client, server, stream, input, getPendingFollowUp): AsyncIterable<ProviderEvent> {
     const session = await client.session.create();
-    yield { type: 'init', continuation: session.data.id };
+    yield { type: 'init', sessionId: session.data.id };
 
     await client.session.promptAsync({
       path: { id: session.data.id },
@@ -407,58 +356,62 @@ The agent-runner transforms messages_in rows into a prompt string. The provider
 
 **Routing field stripping:** `platform_id`, `channel_type`, `thread_id` are never included in the prompt. They're stored as context for writing messages_out.
 
-Every kind renders to a single self-contained XML element. The `id` attribute is the
-message's `seq` (the agent-facing message ID it passes to `edit_message` / `add_reaction`).
-The `from` attribute is the origin destination name (resolved from the routing fields via
-the destination map), so the agent always knows where a message came from — routing fields
-themselves are never shown.
+**Single message formatting by kind:**
 
-- **`chat`** — one `<message>` per row:
+- **`chat`** — format into message XML:
   ```xml
-  <message id="5" from="family" sender="John" time="Jan 1, 10:00 AM">Check this PR</message>
+  <message sender="John" time="2024-01-01 10:00">
+    Check this PR
+  </message>
   ```
-  A reply carries a `reply_to` attribute and an inline `<quoted_message from="…">…</quoted_message>`.
 
-- **`chat-sdk`** — same `<message>` shape, fields extracted from the serialized Chat SDK
-  message. Attachments are appended inline: `[image: screenshot.png — saved to /workspace/…]`
-  or `[image: screenshot.png (https://signed-url…)]`. Images/PDFs that Claude handles
-  natively are also passed as content blocks (see Media Handling below).
-
-- **`task`** — a `<task>` element, script output first when present:
+- **`chat-sdk`** — extract fields from serialized Chat SDK message:
   ```xml
-  <task from="scheduler" time="Jan 1, 9:00 AM">Script output:
-  {"data": …}
+  <message sender="John (john@slack)" time="2024-01-01 10:00">
+    Check this PR
+    [image: screenshot.png — https://signed-url...]
+  </message>
+  ```
+  Attachments are listed inline. Images/PDFs that Claude handles natively are passed as content blocks (see Media Handling below).
+
+- **`task`** — task prompt, optionally with script output:
+  ```
+  [SCHEDULED TASK]
+
+  Script output:
+  {"data": ...}
 
   Instructions:
-  Review open PRs</task>
+  Review open PRs
   ```
 
-- **`webhook`** — a `<webhook>` element wrapping the JSON payload:
-  ```xml
-  <webhook from="github" source="github" event="pull_request">{"action": "opened", …}</webhook>
+- **`webhook`** — webhook payload:
+  ```
+  [WEBHOOK: github/pull_request]
+
+  {"action": "opened", "pull_request": {...}}
   ```
 
-- **`system`** — host action result, rendered as `<system_response>`:
-  ```xml
-  <system_response from="host" action="create_agent" status="success">{"agent_group_id": "ag-456"}</system_response>
+- **`system`** — host action result (response to an earlier system request):
+  ```
+  [SYSTEM RESPONSE]
+
+  Action: register_agent_group
+  Status: success
+  Result: {"agent_group_id": "ag-456"}
   ```
 
-**Batch formatting:** All pending messages are combined into one prompt. The prompt opens
-with a self-closing `<context timezone="<IANA>" />` header (so the agent interprets every
-timestamp — and every time it schedules — in the user's zone), then the chat messages
-concatenated as consecutive `<message>` blocks, then any task/webhook/system elements,
-joined by blank lines:
+**Batch formatting:** Multiple pending messages are combined into one prompt:
 
 ```xml
-<context timezone="America/Los_Angeles" />
-<message id="2" from="family" sender="John" time="10:00">Check this PR</message>
-<message id="4" from="family" sender="Jane" time="10:01">Already on it</message>
+<context timezone="America/Los_Angeles">
+<messages>
+<message sender="John" time="10:00">Check this PR</message>
+<message sender="Jane" time="10:01">Already on it</message>
+</messages>
 ```
 
-There is **no** outer `<messages>` envelope — an earlier revision wrapped multi-message
-batches that way, but the Claude Agent SDK answered the wrapped shape with a synthetic
-"No response requested." stub instead of calling the API (#2555). Dropping the wrapper made
-the single-message path just the N=1 case of the same concatenation.
+Mixed kinds (e.g., a chat message + a system response) are combined with clear delimiters. Each section is labeled by kind.
 
 **Command detection:** Messages starting with `/` are checked against a command list. Recognized commands bypass formatting and are passed raw to the provider (for Claude's slash command handling) or intercepted by the agent-runner (for NanoClaw-level commands like session reset).
 
@@ -477,70 +430,54 @@ interface RoutingContext {
 
 When writing messages_out (either from provider results or MCP tool calls), the agent-runner copies this routing context by default. The agent never sees routing fields — it just produces text. The routing is implicit: "respond to whoever sent the message."
 
-MCP tools that target a named destination (`send_message` / `send_file` with a `to`
-argument) resolve routing through the session's destination map instead of the default
-reply context — including agent-to-agent sends, which are just a `to` pointing at an
-`agent`-type destination.
+MCP tools that target a different destination (e.g., `send_to_agent`, `send_message` with explicit channel) override the routing context for that specific messages_out row.
 
 ### Status Management
 
-`inbound.db` is a read-only mount inside the container, so the agent-runner never writes
-`messages_in`. It tracks processing status in the `processing_ack` table in the
-container-owned `outbound.db`; the host reads `processing_ack` and mirrors completion
-back onto `messages_in.status`.
+The agent-runner manages the `status` and `status_changed` fields on messages_in:
 
 ```
-processing_ack: (no row) → processing → completed
+pending → processing → completed
+                    → failed (if provider returns error and max retries exhausted)
 ```
 
-- **Pick up:** `INSERT OR REPLACE INTO processing_ack (message_id, status, status_changed) VALUES (?, 'processing', now())` for each claimed row (`markProcessing`). Pending queries skip any row already present in `processing_ack`.
-- **Complete:** same upsert with `status = 'completed'` (`markCompleted`). Every consumed batch ends here — error outcomes included. On a provider error the poll-loop writes an error **chat message** to `messages_out` (so the user sees it), then still acks the batch completed; errors surface as messages, not as an ack status. (A `markFailed` helper exists in `messages-in.ts` but currently has no callers.)
-- The host's `syncProcessingAcks` mirrors acked ids onto `messages_in.status = 'completed'`. Its stale/retry policy is driven off the `.heartbeat` file mtime and the `processing_ack` claim timestamps. On startup the agent-runner clears leftover `processing` acks (crash recovery) so orphaned claims re-process.
+- **Pick up:** `UPDATE messages_in SET status = 'processing', status_changed = now(), tries = tries + 1 WHERE id IN (...)`
+- **Complete:** `UPDATE messages_in SET status = 'completed', status_changed = now() WHERE id IN (...)`
+- **Error:** Agent-runner does NOT set `failed` — it leaves the message as `processing`. The host detects stale processing via `status_changed` and handles retry logic (reset to pending with backoff). This keeps retry policy on the host side.
 
 ### MCP Tools
 
-The agent-runner runs an MCP server (stdio) that exposes NanoClaw tools to the agent. The
-tool modules use the same two-DB connection layer as the rest of the runner
-(`container/agent-runner/src/db/connection.ts`): they read the host-written `inbound.db`
-at `/workspace/inbound.db` **read-only** (destinations, session routing, question
-responses, task lists) and write to the container-owned `outbound.db` at
-`/workspace/outbound.db`. There is no shared single-file connection and no WAL — both files
-are `journal_mode=DELETE` because WAL's memory-mapped `-shm` file does not stay coherent
-across the VirtioFS host↔container mount.
+The agent-runner runs an MCP server that exposes NanoClaw tools to the agent. All tools write to the session DB.
+
+**DB path:** The MCP server receives the session DB path via environment variable. It opens a second connection to the same SQLite file (WAL mode allows concurrent access).
 
 #### send_message
 
-Send a chat message to a named destination. Agents address destinations by name, never by
-raw platform/channel/thread IDs — the destination map (`destinations` table in `inbound.db`,
-written by the host) resolves the name to routing fields.
+Send a chat message to the current conversation (or a specified destination).
 
 ```typescript
 {
   name: 'send_message',
   params: {
-    text: string,    // message content (required)
-    to?: string,     // destination name (e.g. "family", "worker-1").
-                     // Optional when the agent has exactly one destination.
+    text: string,          // message content
+    channel?: string,      // optional: target channel type (default: reply to origin)
+    platformId?: string,   // optional: target platform ID
+    threadId?: string,     // optional: target thread ID
   }
 }
 ```
 
-Implementation: `resolveRouting(to)` looks up the destination. With no `to`, it defaults to
-the session's own reply routing (`session_routing`); if the destination resolves to the same
-channel the session is bound to, the session's `thread_id` is preserved so the reply lands
-in-thread, otherwise `thread_id` is null. The tool then writes a `messages_out` row with
-`kind: 'chat'` and content `{ text }`, and returns the new `seq` as the message id.
+Implementation: write a `messages_out` row with `kind: 'chat'`. If channel/platformId/threadId are provided, use those as routing. Otherwise, copy from the current routing context.
 
 #### send_file
 
-Send a file to a named destination (same destination model as `send_message`).
+Send a file to the current conversation.
 
 ```typescript
 {
   name: 'send_file',
   params: {
-    path: string,          // file path (relative to /workspace/agent/ or absolute) (required)
-    to?: string,           // destination name; optional if the agent has one destination
+    path: string,          // file path (relative to /workspace/agent/ or absolute)
     text?: string,         // optional accompanying message
     filename?: string,     // display name (default: basename of path)
   }
@@ -548,10 +485,10 @@ Send a file to a named destination (same destination model as `send_message`).
 ```
 
 Implementation:
-1. Resolve routing via `resolveRouting(to)` (as `send_message`)
-2. Generate a message ID and create `/workspace/outbox/{messageId}/`
-3. Copy the file into that outbox directory
-4. Write a `messages_out` row (`kind: 'chat'`) with content `{ text, files: [filename] }`
+1. Generate a message ID
+2. Create `outbox/{messageId}/` directory
+3. Copy the file into the outbox directory
+4. Write a `messages_out` row with `files: [filename]` in the content
 
 #### send_card
 
@@ -586,11 +523,11 @@ Send an interactive question and wait for the user's response. This is a **block
 ```
 
 Implementation:
-1. Generate a `questionId` and normalize each option to `{ label, selectedLabel, value }`
-2. Write a `messages_out` row with `kind: 'chat-sdk'` and content `{ type: 'ask_question', questionId, title, question, options }`
-3. Poll `inbound.db` (read-only) for a pending `messages_in` row whose content carries the matching `questionId` (`findQuestionResponse`), skipping any already in `processing_ack`
-4. When found, `markCompleted` the response row (a `processing_ack` write in `outbound.db`) and return its `selectedOption` as the tool result
-5. If the deadline passes, return a timeout error as the tool result
+1. Generate a `questionId`
+2. Write a `messages_out` row with `operation: 'ask_question'`, the question, options, and questionId
+3. Poll `messages_in` for a row with matching `questionId` in content
+4. When found, return the `selectedOption` as the tool result
+5. If timeout expires, return a timeout error as the tool result
 
 The agent's execution is paused at this tool call. The provider's query keeps running (Claude holds the tool call open). The agent-runner polls for the response in a separate loop.
 
@@ -626,63 +563,89 @@ Add an emoji reaction to a message.
 
 Implementation: write a `messages_out` row with `operation: 'reaction'`.
 
-#### Agent-to-agent sends (no dedicated tool)
+#### send_to_agent
 
-There is no `send_to_agent` tool. Agents and channels share one destination namespace, so
-messaging another agent is just `send_message(to="<agent-name>")` where the named
-destination is of type `agent`. `resolveRouting` maps it to a `messages_out` row with
-`channel_type: 'agent'` and `platform_id` set to the target agent group id; the host
-validates the send and routes it into the target session's `inbound.db`.
-
-#### ncl tasks
-
-Schedule, inspect, and modify one-shot or recurring tasks.
-
-```bash
-ncl tasks create --prompt "..." --process-after "2026-01-15T09:00:00" --recurrence "0 9 * * *"
-ncl tasks list
-ncl tasks update <series_id> --prompt "..."
-ncl tasks cancel <series_id>
-```
-
-Implementation: the host writes `messages_in` task rows into the agent group's system session (`thread_id = system:tasks`). The host sweep wakes that system-session container when a task is due. The task agent chooses its destination at fire time by emitting `<message to="name">...</message>` or using `send_message`.
-
-#### create_agent
-
-Create a long-lived companion sub-agent. The `name` becomes a destination the creating
-agent can address. (There is no `register_agent_group` tool — this replaced it.)
+Send a message to another agent group.
 
 ```typescript
 {
-  name: 'create_agent',
+  name: 'send_to_agent',
   params: {
-    name: string,           // human-readable name; also the destination name (required)
-    instructions?: string,  // CLAUDE.md content for the new agent (role, personality)
+    agentGroupId: string,  // target agent group
+    text: string,          // message content
+    sessionId?: string,    // optional: target specific session
   }
 }
 ```
 
-Implementation: fire-and-forget. Writes a `messages_out` row with `kind: 'system'`,
-`action: 'create_agent'`, `requestId`, `name`, and `instructions`. The container is
-untrusted and does not gate itself; the host authorizes by CLI scope — trusted owner groups
-(scope `global`) create directly, confined groups require admin approval
-(`src/modules/agent-to-agent/create-agent.ts`) — then creates the entity rows and notifies
-the agent via a chat message when the agent is ready.
+Implementation: write a `messages_out` row with `channel_type: 'agent'`, `platform_id: agentGroupId`, `thread_id: sessionId`.
 
-#### Self-modification: install_packages, add_mcp_server
+#### schedule_task
 
-Two fire-and-forget system-action tools let an agent extend its own runtime (both require
-admin approval, applied host-side):
+Schedule a one-shot or recurring task.
 
-- **`install_packages`** — `{ apt?: string[], npm?: string[], reason?: string }`. Package
-  names are validated at the tool boundary and re-validated on the host. On approval the
-  host rebuilds the per-agent image and restarts the container.
-- **`add_mcp_server`** — `{ name, command, args?, env? }`. Wires an existing third-party MCP
-  server into the agent's `container.json`; on approval the host updates the config and
-  restarts (no rebuild — Bun runs the TS directly).
+```typescript
+{
+  name: 'schedule_task',
+  params: {
+    prompt: string,             // task prompt
+    processAfter: string,       // ISO timestamp for first run
+    recurrence?: string,        // cron expression (optional)
+    script?: string,            // pre-agent script (optional)
+  }
+}
+```
 
-Both write a `messages_out` row with `kind: 'system'` and the matching `action`, then return
-immediately; the host notifies the agent when approval resolves.
+Implementation: the container can't write host-owned `inbound.db`, so this writes a `messages_out` row with `kind: 'system'` and `action: 'schedule_task'` (`container/agent-runner/src/mcp-tools/scheduling.ts`). During delivery the host's action handler (`src/modules/scheduling/actions.ts` → `insertTask()` in `src/modules/scheduling/db.ts`) inserts the `kind: 'task'` row into `inbound.db` with `process_after` and optionally `recurrence`. The host sweep picks it up when due.
+
+#### list_tasks
+
+List active scheduled/recurring tasks.
+
+```typescript
+{
+  name: 'list_tasks',
+  params: {}
+}
+```
+
+Implementation: a read, not a write — the container may read the read-only `inbound.db` mount directly. Returns one row per series (the live pending/paused occurrence): `SELECT series_id AS id, ... FROM messages_in WHERE kind = 'task' AND status IN ('pending','paused') GROUP BY series_id`. See `container/agent-runner/src/mcp-tools/scheduling.ts`.
+
+#### cancel_task / pause_task / resume_task / update_task
+
+Modify a scheduled task.
+
+```typescript
+{
+  name: 'cancel_task',
+  params: { taskId: string }
+}
+// pause_task: set status = 'paused' (new status value for recurring tasks)
+// resume_task: set status = 'pending'
+// update_task: merge { prompt?, recurrence?, processAfter?, script? } into the live row
+```
+
+Implementation: all four are sent as system actions (`messages_out`, `kind: 'system'`, `action: 'cancel_task' | 'pause_task' | 'resume_task' | 'update_task'`) — the container never writes `inbound.db`. The host's handlers in `src/modules/scheduling/actions.ts` apply the change against `inbound.db` via `src/modules/scheduling/db.ts`: cancel/pause/resume flip status on the live row(s); update_task reads current content, merges supplied fields, and writes back. All four match by `(id = ? OR series_id = ?) AND kind='task' AND status IN ('pending','paused')`, so they reach the live next occurrence of a recurring task even when the agent passes the original (now-completed) id.
+
+#### register_agent_group
+
+Register a new agent group (admin only).
+
+```typescript
+{
+  name: 'register_agent_group',
+  params: {
+    name: string,
+    folder: string,
+    platformId: string,        // messaging group to wire to
+    channelType: string,
+    triggerRules?: object,
+    sessionMode?: 'shared' | 'per-thread',
+  }
+}
+```
+
+Implementation: write a `messages_out` row with `kind: 'system'`, `action: 'register_agent_group'`. The host reads, validates admin permission, creates the entity rows in the central DB, and writes a `system` messages_in response.
 
 ### Media Handling
 
@@ -738,20 +701,12 @@ Archive location: `/workspace/agent/conversations/{date}-{summary}.md`
 
 ### Session Resume
 
-The agent-runner tracks a single opaque `continuation` token per provider:
+The agent-runner tracks `sessionId` and `resumeAt` across queries:
 
-- Captured from `ProviderEvent { type: 'init', continuation }` and persisted to the
-  `session_state` table in `outbound.db` under the key `continuation:<provider>` (keyed per
-  provider because a continuation is provider-private — a Claude session id is meaningless to
-  another provider).
-- Passed back as `QueryInput.continuation` on the next query. For Claude that becomes the
-  SDK `resume` option; the SDK reloads its on-disk `.jsonl` transcript for that session id.
+- `sessionId` — captured from `ProviderEvent { type: 'init' }`. Passed back to `QueryInput.sessionId` on the next query.
+- `resumeAt` — Claude-specific (last assistant message UUID). Stored by the agent-runner, passed to `QueryInput.resumeAt`. Providers that don't support this ignore it.
 
-Because it lives in the session folder's `outbound.db`, the continuation survives container
-teardown and restart — a fresh container reads it back and resumes. `/clear` deletes the row
-to start a clean session. Before resuming, `maybeRotateContinuation` may archive and drop an
-oversized/aged transcript (so a cold container isn't killed reloading it), and
-`isSessionInvalid` clears a continuation whose backing transcript has gone missing.
+These are ephemeral to the container's lifetime. When the container is killed and restarted, the host passes the stored `sessionId` from the central DB's sessions table. `resumeAt` is lost on container restart (the provider resumes from the end of the session).
 
 ### Container Startup
 
@@ -759,7 +714,7 @@ The agent-runner receives configuration via:
 
 - **`container.json`:** The provider name, model, assistant name, MCP servers, and other NanoClaw config are read from `/workspace/agent/container.json` (materialized by the host from the `container_configs` table), not from environment variables. See `container/agent-runner/src/config.ts`.
 - **Environment variables:** provider-specific vars only (API keys, model overrides), `TZ`.
-- **Fixed mount paths:** Host-written `inbound.db` (read-only) at `/workspace/inbound.db` and container-owned `outbound.db` at `/workspace/outbound.db`. Agent group folder at `/workspace/agent/`. System prompt from `/workspace/agent/CLAUDE.md` and `/workspace/global/CLAUDE.md`.
+- **Fixed mount paths:** Session DB at `/workspace/session.db`. Agent group folder at `/workspace/agent/`. System prompt from `/workspace/agent/CLAUDE.md` and `/workspace/global/CLAUDE.md`.
 
 The agent-runner reads config, creates the provider, and enters the poll loop. No stdin, no initial prompt — messages are already in the session DB.
 

docs/api-details.md

@@ -13,8 +13,6 @@ interface ChannelSetup {
 
   // Host callbacks
   onInbound(platformId: string, threadId: string | null, message: InboundMessage): void;
-  // Admin-transport adapters (e.g. CLI) route to an arbitrary channel via this instead of onInbound
-  onInboundEvent(event: InboundEvent): void;
   onMetadata(platformId: string, name?: string, isGroup?: boolean): void;
 }
 
@@ -36,7 +34,7 @@ interface ChannelAdapter {
   isConnected(): boolean;
 
   // Outbound delivery
-  deliver(platformId: string, threadId: string | null, message: OutboundMessage): Promise<string | undefined>;
+  deliver(platformId: string, threadId: string | null, message: OutboundMessage): Promise<void>;
 
   // Optional
   setTyping?(platformId: string, threadId: string | null): Promise<void>;
@@ -59,52 +57,6 @@ interface OutboundMessage {
 }
 ```
 
-### Channel Defaults
-
-Each adapter can declare static wiring-time defaults. There are exactly two levels: the adapter declaration, and the per-wiring/per-messaging-group values chosen at creation. There is no DB config table for defaults — install-wide changes mean editing the adapter copy (skill-installed, user-owned).
-
-```typescript
-// src/channels/adapter.ts
-interface ChannelContextDefaults {
-  engageMode: 'pattern' | 'mention' | 'mention-sticky';
-  engagePattern?: string;   // required iff engageMode='pattern'; may contain the
-                            // literal token {name} — creation helpers substitute the
-                            // regex-escaped agent_group name
-  threads: boolean;         // whether thread ids are honored in this context by default;
-                            // must be false when the adapter's supportsThreads is false
-  unknownSenderPolicy: 'strict' | 'request_approval' | 'public';
-}
-
-interface ChannelDefaults {
-  dm: ChannelContextDefaults;
-  group: ChannelContextDefaults;
-  mentions: 'platform' | 'dm-only' | 'never';
-  // 'platform' — platform-confirmed mentions in groups, DMs flagged too
-  // 'dm-only'  — only DMs flagged (no group mention metadata)
-  // 'never'    — isMention never set: no auto-create card, mention wirings never engage
-}
-
-// ChannelAdapter and ChannelRegistration both carry an optional `defaults` field.
-// The registration-level copy lets offline creation paths (setup/register.ts,
-// scripts/init-first-agent.ts) resolve declarations without instantiating the
-// adapter. ChatSdkBridgeConfig.defaults is copied verbatim onto the bridged
-// adapter, like supportsThreads.
-```
-
-**Resolution chain** (`getChannelDefaults(key, channelType?)` in `src/channels/channel-registry.ts`, key = `mg.instance ?? mg.channel_type`, same discipline as `getChannelAdapter`):
-
-1. Live adapter's `defaults`, instance-exact (lets an instance carry env-computed declarations, e.g. WhatsApp shared-number mode)
-2. Live adapter of that channelType
-3. Registration entry under the key
-4. Registration entry under the channelType (from the live adapter's channelType, else the caller-supplied hint)
-5. `fallbackChannelDefaults(supportsThreads)` — behavior-faithful to the pre-declaration router: dm `{ pattern '.', threads: supportsThreads, request_approval }`, group `{ mention-sticky, threads: supportsThreads, request_approval }`, mentions `'platform'`. `supportsThreads` is `false` when no adapter is live.
-
-Never returns undefined. `hasDeclaredChannelDefaults()` reports whether tiers 1–4 hit; manual creation surfaces (`ncl`) gate declaration-derived defaults on it so stale (undeclared) adapters keep the legacy static schema defaults — a trunk update alone changes no behavior.
-
-**Creation helpers** (`src/channels/channel-defaults.ts`): every wiring-creation path calls `resolveWiringDefaults(channelKey, isGroup, agentGroupName)` — it picks `decl.group` vs `decl.dm` by `isGroup = event.message.isGroup ?? (mg.is_group === 1)` (never `threadId !== null`), substitutes `{name}`, and downgrades `mention-sticky` → `mention` when the context's resolved threads value is false. `resolveUnknownSenderPolicy` does the same for auto-created messaging_groups rows.
-
-**Runtime thread policy**: engage mode and sender policy are creation-time snapshots; threading is the one setting consulted live. `messaging_group_agents.threads` (migration 019) is the per-wiring override: `NULL` = inherit the adapter declaration for the wiring's context, `1`/`0` = explicit. `resolveThreadPolicy(wiring.threads, decl, isGroup, supportsThreads)` hard-ANDs the result with the adapter's raw capability — a wiring can opt out of threads on a threaded platform, never opt in on a non-threaded one. When the policy is off, event-derived thread ids are nulled at router fanout (sessions collapse, replies land top-level); `event.replyTo` is operator intent from the CLI transport and is never nulled.
-
 ### Chat SDK Bridge
 
 Wraps a Chat SDK adapter + Chat instance to conform to the NanoClaw ChannelAdapter interface. Trunk ships the bridge and the channel registry only — platform-specific Chat SDK adapters (Discord, Slack, Telegram, etc.) and native adapters (WhatsApp/Baileys) are installed by the `/add-<channel>` skills from the `channels` branch.
@@ -355,7 +307,7 @@ function createWhatsAppChannel(): ChannelAdapter {
 **Ask user question:**
 ```json
 {
-  "type": "ask_question",
+  "operation": "ask_question",
   "questionId": "q-123",
   "title": "Failing Test",
   "question": "How should we handle the failing test?",

docs/architecture-diagram.html

@@ -311,6 +311,7 @@ erDiagram
     string name
     string folder
     string agent_provider
+    json container_config
   }
   messaging_groups {
     int id
@@ -343,15 +344,14 @@ erDiagram
     int messaging_group_id
     int agent_group_id
     string session_mode
-    string engage_mode "pattern | mention | mention-sticky"
-    string sender_scope "all | known"
+    json trigger_rules
     int priority
   }
   sessions {
     int id
     int agent_group_id
     int messaging_group_id
-    string thread_id
+    string sdk_session_id
     string status
   }
 </pre>
@@ -391,7 +391,7 @@ flowchart LR
   Container -->|writes · odd seq| Out
   Container -->|touch every poll| HB
   HostSweep[Host sweep] -->|stat mtime| HB
-  HostSweep -->|reads processing_ack| Out
+  HostSweep -->|reads processing_ack| In
 </pre>
         </div>
       </section>

docs/architecture-diagram.md

@@ -28,18 +28,18 @@ flowchart TB
     Approvals["configureManualApproval<br/>-> pending_approvals"]
   end
 
-  subgraph Session["Per-Session Container (Docker)"]
+  subgraph Session["Per-Session Container (Docker / Apple Container)"]
     direction TB
     PollLoop["Poll Loop<br/>(container/agent-runner)"]
-    Provider["Agent providers<br/>(claude — the only one registered in trunk;<br/>opencode ships via the /add-opencode skill)"]
-    MCP["MCP Tools<br/>send_message, send_file, edit_message,<br/>add_reaction, send_card, ask_user_question,<br/>create_agent, install_packages, add_mcp_server<br/>CLI: ncl tasks"]
+    Provider["Agent providers<br/>(claude, opencode; todo: codex)"]
+    MCP["MCP Tools<br/>send_message, send_file, edit_message,<br/>add_reaction, send_card, ask_user_question,<br/>schedule_task, create_agent,<br/>install_packages, add_mcp_server"]
     Skills["Container Skills<br/>(container/skills/)"]
-    InDB[("inbound.db<br/>host writes<br/>even seq<br/>messages_in<br/>delivered<br/>destinations<br/>session_routing")]
-    OutDB[("outbound.db<br/>container writes<br/>odd seq<br/>messages_out<br/>processing_ack<br/>session_state<br/>container_state<br/>heartbeat file")]
+    InDB[("inbound.db<br/>host writes<br/>even seq<br/>messages_in<br/>destinations<br/>processing_ack")]
+    OutDB[("outbound.db<br/>container writes<br/>odd seq<br/>messages_out<br/>heartbeat file")]
   end
 
   subgraph Groups["Agent Group Filesystem (groups/*)"]
-    Folder["CLAUDE.md<br/>memory<br/>per-group skills<br/>container.json (materialized from container_configs)"]
+    Folder["CLAUDE.md<br/>memory<br/>per-group skills<br/>container_config"]
   end
 
   P1 & P2 & P3 & P4 & P5 --> Bridge
@@ -140,6 +140,7 @@ erDiagram
     string name
     string folder
     string agent_provider
+    json container_config
   }
   messaging_groups {
     int id
@@ -172,15 +173,14 @@ erDiagram
     int messaging_group_id
     int agent_group_id
     string session_mode "agent-shared | shared | per-thread"
-    string engage_mode "pattern | mention | mention-sticky"
-    string sender_scope "all | known"
+    json trigger_rules
     int priority
   }
   sessions {
     int id
     int agent_group_id
     int messaging_group_id
-    string thread_id
+    string sdk_session_id
     string status
   }
 ```
@@ -209,7 +209,7 @@ flowchart LR
   Container -->|"writes only<br/>(odd seq)"| Out
   Container -->|touch every poll| HB
   HostSweep[Host sweep] -->|stat mtime| HB
-  HostSweep -->|reads processing_ack| Out
+  HostSweep -->|reads processing_ack| In
 
   note1["Each file has exactly ONE writer.<br/>Eliminates SQLite cross-process write contention.<br/>Collision-free seq numbering."]
 ```

docs/architecture.md

@@ -4,17 +4,7 @@
 
 ## Core Idea
 
-Each agent session has a **pair** of mounted SQLite DBs. They are the one and only IO
-mechanism between host and container. No IPC files, no stdin piping. `inbound.db` carries
-host → agent-runner messages (`messages_in`); `outbound.db` carries agent-runner → host
-messages (`messages_out`) plus the container's processing acks. Everything is a message.
-
-The split exists so each file has exactly one writer: the host writes `inbound.db` (the
-container opens it read-only) and the container writes `outbound.db` (the host opens it
-read-only). One writer per file means no cross-process lock contention over the
-host↔container mount. Both files run `journal_mode=DELETE`, **not** WAL: WAL's memory-mapped
-`-shm` coherency does not propagate across VirtioFS, so a WAL reader in the guest would
-freeze on an early snapshot and never see new host writes.
+Each agent session has a mounted SQLite DB. The DB is the one and only IO mechanism between host and container. No IPC files, no stdin piping. Two tables: messages_in (host → agent-runner) and messages_out (agent-runner → host). Everything is a message.
 
 ## Two-Level DB
 
@@ -23,18 +13,15 @@ freeze on an early snapshot and never see new host writes.
 - Maps platform IDs → agent groups → sessions
 - Channel adapters don't touch this directly — the host does the lookup
 
-**Per-session DBs (mounted into container):**
-- `inbound.db` → `messages_in` (written by host, read-only in container) plus host-written
-  lookup tables the container reads live: `destinations`, `session_routing`, `delivered`
-- `outbound.db` → `messages_out` (written by agent-runner, read by host) plus
-  `processing_ack`, `session_state`, and `container_state` (all container-owned)
-- Everything is a message: chat, tasks, webhooks, system actions, agent-to-agent — all use
-  `messages_in` / `messages_out`
-- One pair per session, not per agent group
+**Per-session DB (mounted into container):**
+- messages_in (written by host, read by agent-runner)
+- messages_out (written by agent-runner, read by host)
+- Everything is a message: chat, tasks, webhooks, system actions, agent-to-agent — all use these two tables
+- One DB per session, not per agent group
 
 ## Agent Groups vs Sessions
 
-An agent group has its own filesystem — folder, CLAUDE.md, skills, container config. Multiple sessions can share the same agent group (same filesystem, same skills) but each session gets its own `inbound.db`/`outbound.db` pair mounted at known paths. Each session = a separate container with the same agent group's filesystem but a different DB pair.
+An agent group has its own filesystem — folder, CLAUDE.md, skills, container config. Multiple sessions can share the same agent group (same filesystem, same skills) but each session gets its own DB mounted at a known path. Each session = a separate container with the same agent group's filesystem but a different session DB.
 
 ## Message Flow
 
@@ -43,13 +30,13 @@ Platform event
   → Channel adapter (trigger check, ID extraction)
   → Returns: { platformChannelId, platformThreadId, triggered }
   → Host maps platformChannelId + platformThreadId → agent group + session
-  → Host writes messages_in row to the session's inbound.db
+  → Host writes message to session's DB
   → Host calls wakeUpAgent(session)
   → Container spins up (or is already running)
-  → Agent-runner polls inbound.db (read-only), finds new messages
-  → Agent-runner processes with the configured provider
-  → Agent-runner writes response to messages_out in outbound.db
-  → Host polls active sessions' outbound.db for responses
+  → Agent-runner polls its session DB, finds new messages
+  → Agent-runner processes with Claude
+  → Agent-runner writes response to session DB
+  → Host polls active session DBs for responses
   → Host reads response, looks up conversation, delivers through channel adapter
 ```
 
@@ -144,7 +131,7 @@ The host is an orchestrator:
 1. **Spawn** — when wakeUpAgent is called and no container exists for the session
 2. **Idle kill** — when a container has no unprocessed messages for some timeout period
 
-When a container spins up, the agent-runner immediately starts polling `inbound.db`. Messages are already there waiting.
+When a container spins up, the agent-runner immediately starts polling its session DB. Messages are already there waiting.
 
 ## Media Handling
 
@@ -198,66 +185,50 @@ Dedup is the channel adapter's responsibility. Chat SDK handles this internally.
 
 ## Session DB Schema
 
-Split across the two files. JSON blobs for content — schema-free, format varies by `kind`.
-`seq` is a global ordering counter with a **disjoint parity**: the host writes even seqs to
-`messages_in`, the container writes odd seqs to `messages_out`. Each side reads the other's
-MAX(seq) to pick its next value, so seq is a single monotonic message id across both tables —
-which is why the agent-facing message id it returns from `send_message` (and accepts in
-`edit_message` / `add_reaction`) is unambiguous.
+Two tables. JSON blobs for content — schema-free, format varies by `kind`.
 
 ```sql
--- inbound.db — host writes, container opens read-only
+-- Host writes, agent-runner reads
 CREATE TABLE messages_in (
   id             TEXT PRIMARY KEY,
-  seq            INTEGER UNIQUE,     -- even (host-assigned)
   kind           TEXT NOT NULL,      -- 'chat' | 'chat-sdk' | 'task' | 'webhook' | 'system'
   timestamp      TEXT NOT NULL,
-  status         TEXT DEFAULT 'pending',  -- host-owned; the host mirrors the container's
-                                          -- processing_ack terminal states onto this column
+  status         TEXT DEFAULT 'pending',  -- 'pending' | 'processing' | 'completed' | 'failed'
+  status_changed TEXT,               -- ISO timestamp of last status change
   process_after  TEXT,               -- ISO timestamp. NULL = process immediately.
   recurrence     TEXT,               -- cron expression. NULL = one-shot.
-  series_id      TEXT,               -- groups a recurring task's occurrences
   tries          INTEGER DEFAULT 0,  -- number of processing attempts
-  trigger        INTEGER NOT NULL DEFAULT 1,  -- 0 = accumulated context (don't wake), 1 = wake
-  platform_id    TEXT,               -- routing (stripped before the agent sees content)
+
+  -- routing (agent-runner copies to messages_out; agent never sees these)
+  platform_id    TEXT,
   channel_type   TEXT,
   thread_id      TEXT,
-  content        TEXT NOT NULL,      -- JSON blob (structure depends on kind)
-  source_session_id TEXT,            -- a2a return path: source session that emitted the trigger
-  on_wake        INTEGER NOT NULL DEFAULT 0  -- 1 = only deliver on a container's first poll
+
+  -- payload (structure depends on kind)
+  content        TEXT NOT NULL        -- JSON blob
 );
 
--- outbound.db — container writes, host opens read-only
+-- Agent-runner writes, host reads
 CREATE TABLE messages_out (
   id             TEXT PRIMARY KEY,
-  seq            INTEGER UNIQUE,     -- odd (container-assigned)
-  in_reply_to    TEXT,              -- references messages_in.id (optional)
+  in_reply_to    TEXT,               -- references messages_in.id (optional)
   timestamp      TEXT NOT NULL,
-  deliver_after  TEXT,              -- ISO timestamp. NULL = deliver immediately.
-  recurrence     TEXT,              -- cron expression. NULL = one-shot.
-  kind           TEXT NOT NULL,     -- copied from messages_in by default
-  platform_id    TEXT,              -- routing (default: copied from messages_in)
+  delivered      INTEGER DEFAULT 0,
+  deliver_after  TEXT,               -- ISO timestamp. NULL = deliver immediately.
+  recurrence     TEXT,               -- cron expression. NULL = one-shot.
+
+  -- routing (default: copied from messages_in by agent-runner)
+  kind           TEXT NOT NULL,      -- 'chat' | 'chat-sdk' | 'task' | 'webhook' | 'system'
+  platform_id    TEXT,
   channel_type   TEXT,
   thread_id      TEXT,
-  content        TEXT NOT NULL      -- JSON blob (format matches kind)
+
+  -- payload (format matches kind)
+  content        TEXT NOT NULL        -- JSON blob
 );
 
--- outbound.db — container's processing status (it can't write inbound.db).
--- Host reads this to drive the message lifecycle; stale 'processing' rows are
--- cleared on container startup (crash recovery).
-CREATE TABLE processing_ack (
-  message_id     TEXT PRIMARY KEY,  -- references messages_in.id
-  status         TEXT NOT NULL,     -- 'processing' | 'completed' | 'failed'
-  status_changed TEXT NOT NULL
-);
 ```
 
-Delivery is tracked host-side in a `delivered` table in `inbound.db` (not a column on
-`messages_out`, which the host can't write). `inbound.db` also holds the host-written
-`destinations` and `session_routing` tables the container reads live; `outbound.db` also
-holds `session_state` (the resume continuation, per provider) and `container_state`
-(current tool in flight).
-
 ### Scheduling
 
 One-shot and recurring tasks use the same tables — no separate scheduler.
@@ -266,10 +237,10 @@ One-shot and recurring tasks use the same tables — no separate scheduler.
 
 **Recurring:** Same, plus a `recurrence` cron expression. After the host marks a row as handled/delivered, if `recurrence` is set, it inserts a new row with `process_after`/`deliver_after` advanced to the next cron occurrence. Next time is computed from the scheduled time (not wall clock) to prevent drift.
 
-**Host sweep** (every ~60s across all sessions):
-- `inbound.db` → `messages_in WHERE status = 'pending' AND (process_after IS NULL OR process_after <= now())` → wake agent
-- A `processing_ack` (in `outbound.db`) whose claim, or the `.heartbeat` mtime, is older than the stale threshold → stale detection, increment tries, reschedule `process_after` with backoff
-- `outbound.db` → due `messages_out` rows not yet in the host's `delivered` table (in `inbound.db`) → deliver
+**Host sweep** (every ~60s across all session DBs):
+- `messages_in WHERE status = 'pending' AND (process_after IS NULL OR process_after <= now())` → wake agent
+- `messages_in WHERE status = 'processing' AND status_changed < (now - stale_threshold)` → stale detection, increment tries, reset to pending with backoff
+- `messages_out WHERE delivered = 0 AND (deliver_after IS NULL OR deliver_after <= now())` → deliver
 - After completing/delivering a row with `recurrence`, insert next occurrence
 
 **Active container poll** (~1s) checks the same conditions but only for sessions with running containers.
@@ -361,7 +332,7 @@ Two patterns, both handled at the host level:
 
 In both cases, the approval and action execution happen on the host side, not the agent side.
 
-**Approval routing:** Privilege is a user-level concept. `user_roles` records `owner` (global only — first user to pair becomes owner) and `admin` (global or scoped to a specific `agent_group_id`). When an action requires approval, `pickApprover(agentGroupId)` returns candidates in order: scoped admins for that agent group → global admins → owners (deduplicated). `pickApprovalDelivery` then takes the first candidate reachable via `ensureUserDm` (with a same-channel-kind tie-break so a Discord approval request prefers a Discord-using approver). The approval card lands in the approver's DM messaging group, not the origin chat. Delivery is resolved through the Chat SDK's `openDM` for resolution-required channels (Discord/Slack/…) or the user's handle directly for direct-addressable channels (Telegram/WhatsApp/…), and the mapping is cached in `user_dms` for subsequent requests. See `src/modules/permissions/access.ts` and `src/modules/permissions/user-dm.ts` (`ensureUserDm`); the approver-picking primitives live in `src/modules/approvals/primitive.ts`.
+**Approval routing:** Privilege is a user-level concept. `user_roles` records `owner` (global only — first user to pair becomes owner) and `admin` (global or scoped to a specific `agent_group_id`). When an action requires approval, `pickApprover(agentGroupId)` returns candidates in order: scoped admins for that agent group → global admins → owners (deduplicated). `pickApprovalDelivery` then takes the first candidate reachable via `ensureUserDm` (with a same-channel-kind tie-break so a Discord approval request prefers a Discord-using approver). The approval card lands in the approver's DM messaging group, not the origin chat. Delivery is resolved through the Chat SDK's `openDM` for resolution-required channels (Discord/Slack/…) or the user's handle directly for direct-addressable channels (Telegram/WhatsApp/…), and the mapping is cached in `user_dms` for subsequent requests. See `src/access.ts`, `src/user-dm.ts`.
 
 **Editing a sent message:**
 
@@ -438,16 +409,14 @@ This is documented as a pattern, not a built-in feature.
 
 ## Design Decisions
 
-**Session DB location:** Not in the agent group folder. Separate directory (e.g., `sessions/{session_id}/`). Each session gets its own folder containing `inbound.db`, `outbound.db`, and — when using the claude provider — the SDK's `.claude/` directory. The session identity IS the folder. The SDK's resume token (session id) is persisted in `outbound.db`'s `session_state` table, so a fresh container picks the conversation back up without the host tracking it centrally.
+**Session DB location:** Not in the agent group folder. Separate directory (e.g., `sessions/{session_id}/`). Each session gets its own folder containing `session.db` and the Claude SDK's `.claude/` directory. The session identity IS the folder — no need to track Claude SDK session IDs.
 
 **Container mount structure:**
 
 ```
 /workspace/                 ← mount: session folder (read-write)
-  .claude/                  ← Claude SDK session data / transcripts (auto-created)
-  inbound.db                ← host writes, container reads (opened read-only)
-  outbound.db               ← container writes, host reads (opened read-only)
-  .heartbeat                ← container touches this; host watches its mtime
+  .claude/                  ← Claude SDK session data (auto-created)
+  session.db                ← session SQLite DB
   outbox/                   ← agent-runner writes outbound files here
   agent/                    ← mount: agent group folder (nested, read-write)
     CLAUDE.md               ← agent instructions
@@ -455,17 +424,11 @@ This is documented as a pattern, not a built-in feature.
     ... working files
 ```
 
-Two directory mounts: session folder at `/workspace`, agent group folder at `/workspace/agent/`. The agent-runner CDs into `/workspace/agent/` to run the agent. Claude SDK writes `.claude/` at `/workspace/.claude/` (root of the workspace).
+Two directory mounts: session folder at `/workspace`, agent group folder at `/workspace/agent/`. The agent-runner CDs into `/workspace/agent/` to run the agent. Claude SDK writes `.claude/` at `/workspace/.claude/` (root of the workspace). The session DB is at `/workspace/session.db`.
 
-The runtime is Docker (`src/container-runtime.ts` hardcodes the `docker` binary); nested bind mounts make this layout straightforward. The layout deliberately sticks to directory mounts (no file-level mounts) so it stays portable to runtimes that only support directory mounts.
+This works on both Docker (nested bind mounts) and Apple Container (directory mounts only — no file-level mounts, but nested directory mounts are supported).
 
-**Cross-mount DB access:** The two files exist precisely so each has a single writer — the
-host writes `inbound.db`, the container writes `outbound.db` — which removes writer
-contention across the mount. Both files use `journal_mode=DELETE`, **not** WAL: WAL keeps its
-index in a memory-mapped `-shm` file, and VirtioFS does not propagate that mmap coherency
-from host to guest, so a WAL reader in the container would freeze on an early snapshot and
-silently never see new host writes. Readers that must see fresh host writes promptly (the
-`messages_in` poll) open `inbound.db` with `mmap_size = 0` to bypass SQLite's page cache.
+**Session DB concurrent access:** The host writes messages_in, the agent-runner writes messages_out. Both access the same SQLite file simultaneously. WAL mode handles this — SQLite allows concurrent readers, and the two sides write to different tables so writer contention is minimal. The host enables WAL mode when creating the session DB.
 
 **Session management:** Host-managed. The host creates session folders and mounts them. The container only sees its own session folder.
 
@@ -476,7 +439,7 @@ silently never see new host writes. Readers that must see fresh host writes prom
 3. More messages arrive before container starts → host finds the existing session, writes to the same session DB
 4. Container starts, mounts the folder, agent-runner finds messages waiting
 
-The central DB session row creation is the serialization point. No provider session ID to coordinate — the SDK discovers its own session data in `.claude/` when the agent runs.
+The central DB session row creation is the serialization point. No Claude SDK session ID to coordinate — the SDK discovers its own session data in `.claude/` when the agent runs.
 
 **System actions:** The agent uses MCP tools (register group, reset session, schedule task, etc.). The agent-runner handles these tool calls and writes a structured, deterministic messages_out row with `kind: 'system'`. This is not natural language — it's a programmatic, structured payload that the host processes deterministically. Host validates permissions, executes, and writes the result back as a `system` messages_in row.
 
@@ -486,9 +449,7 @@ The central DB session row creation is the serialization point. No provider sess
 
 ### Output Delivery
 
-NanoClaw does not stream tokens to users. The provider's query interface yields complete results, but a result's text is not delivered as-is: the agent-runner parses it for `<message to="name">...</message>` blocks (`dispatchResultText` in poll-loop.ts) and writes one messages_out row per block, addressed to that destination with its thread context resolved per destination. Everything outside a block — including `<internal>...</internal>` — is scratchpad: logged, never sent. A block naming an unknown destination is dropped into the scratchpad log.
-
-If a result produced text but no valid block, the agent-runner pushes a one-time `<system>` nudge into the live turn asking the agent to re-wrap its response. The exception is a non-retryable error result (e.g. a billing error) with no envelope, which is delivered as an error notice instead of being dropped as scratchpad. Mid-turn interim updates go out through the `send_message` MCP tool; the final-text envelope parsing is how a turn's reply reaches the user. The host delivers complete messages_out rows to channels.
+NanoClaw does not stream tokens to users. The Claude Agent SDK's `query()` yields complete results. The agent-runner writes one complete message to messages_out per result. The host delivers complete messages to channels.
 
 Message editing is supported as an explicit operation (agent calls an `edit_message` tool), not as a streaming mechanism.
 
@@ -496,30 +457,21 @@ Typing indicators: host sets typing when a container is active for a session, cl
 
 ### Message Batching
 
-When multiple messages arrive while the container is down, they accumulate as `status = 'pending'` rows in `messages_in`. When the container wakes up, the agent-runner reads all pending messages (those not yet in `processing_ack`) and processes them as a batch — formatted as a `<context timezone="…" />` header followed by the messages concatenated as consecutive `<message>` blocks. (There is no `<messages>` wrapper element; see [agent-runner-details.md](agent-runner-details.md#message-formatting).)
+When multiple messages arrive while the container is down, they accumulate as `handled = 0` rows in messages_in. When the container wakes up, the agent-runner queries all unhandled messages and processes them as a batch — multiple messages are formatted into a single `<messages>` XML block.
 
 ### Message Lifecycle
 
 ```
-messages_in.status:   pending ──────────► completed (mirrored from ack)
-                              └─────────► failed (host-set, retries exhausted)
-processing_ack.status:         processing → completed
+pending → processing → completed
+                    → failed (after max retries)
 ```
 
-Because `inbound.db` is read-only in the container, the agent-runner never mutates
-`messages_in.status`. It records lifecycle in `processing_ack` (in `outbound.db`); the host
-reads that and mirrors completion back.
+- **pending**: Written by host. Ready to be picked up (if `process_after` is null or past).
+- **processing**: Agent-runner sets this when it picks up the message. `status_changed` is set to now. Prevents other polls from re-picking the same message.
+- **completed**: Agent-runner sets this after successful processing.
+- **failed**: Set after max retries exhausted.
 
-- **pending**: Host writes the `messages_in` row. Ready to be picked up (if `process_after` is null or past).
-- **processing**: Agent-runner upserts a `processing_ack` row (`status = 'processing'`) when it claims the message. Subsequent polls skip any id already in `processing_ack`, so it isn't re-picked.
-- **completed**: Agent-runner sets `processing_ack.status = 'completed'` for **every** consumed batch, error outcomes included — a provider error is surfaced to the user as an error chat message in `messages_out`, then the batch is still acked completed. The host's `syncProcessingAcks` copies it onto `messages_in.status`.
-- **failed**: Set by the **host** (sweep's `markMessageFailed`) when retries are exhausted — never by the container.
-
-**Liveness / stale detection**: The container touches a `/workspace/.heartbeat` file rather
-than writing the DB. The host sweep watches that mtime (widening its tolerance when
-`container_state` shows a long-declared Bash running) to decide a container has crashed, then
-increments `tries` and reschedules `process_after` with exponential backoff. On the next
-container startup, leftover `processing` acks are cleared so orphaned claims re-process.
+**Stale detection**: If a message is `processing` but `status_changed` is too old (e.g., >10 minutes), the host assumes the container crashed. It resets the message to `pending`, increments `tries`, and sets `process_after` with exponential backoff.
 
 ### Error Handling and Retries
 
@@ -643,15 +595,13 @@ src/db/
 - **No inline ALTER TABLE.** A migration runner with a `schema_version` table replaces `try { ALTER TABLE } catch { /* exists */ }` blocks. On startup, it checks the current version and applies pending migrations in order. Each migration is a function: `(db: Database) => void`.
 - **Skills add migrations.** A skill that needs a new column adds a new numbered migration file. No conflicts with other skills' migrations as long as numbers don't collide (use timestamps or high-enough numbers for skill branches).
 
-**Agent-runner session DBs** use the same pattern but lighter — no migrations needed since the DB files are created fresh by the host:
+**Agent-runner session DB** uses the same pattern but lighter — no migrations needed since session DBs are created fresh by the host:
 
 ```
 container/agent-runner/src/db/
-  connection.ts          ← open inbound.db (read-only) + outbound.db (DELETE mode) at fixed paths
-  messages-in.ts         ← read pending from inbound.db, ack via processing_ack in outbound.db
-  messages-out.ts        ← write results/outbox rows to outbound.db (odd seq)
-  session-state.ts       ← resume continuation, keyed per provider
-  session-routing.ts     ← read the host-written default reply routing
+  connection.ts          ← open session.db at fixed path, WAL mode
+  messages-in.ts         ← read pending, update status
+  messages-out.ts        ← write results, outbox queries
   index.ts               ← barrel
 ```
 
@@ -714,13 +664,9 @@ CREATE TABLE agent_groups (
   name             TEXT NOT NULL,
   folder           TEXT NOT NULL UNIQUE,
   agent_provider   TEXT,              -- default for sessions (null = system default)
+  container_config TEXT,              -- JSON: { additionalMounts, timeout }
   created_at       TEXT NOT NULL
 );
--- Container config is NOT a column here — it lives in a separate container_configs
--- table (migration 014), keyed by agent_group_id, with columns: provider, model,
--- effort, image_tag, assistant_name, max_messages_per_prompt, cli_scope, and JSON
--- columns skills / mcp_servers / packages_apt / packages_npm / additional_mounts.
--- The host materializes it into /workspace/agent/container.json for the container.
 
 -- Platform groups/channels (WhatsApp group, Slack channel, Discord channel, email thread, etc.)
 -- One row per chat PER ADAPTER INSTANCE. instance defaults to channel_type
@@ -775,21 +721,16 @@ CREATE TABLE user_dms (
   PRIMARY KEY (user_id, channel_type)
 );
 
--- Which agent groups handle which messaging groups, with what rules.
--- The opaque trigger_rules JSON + response_scope enum were replaced (migration
--- 010) by four orthogonal axes:
+-- Which agent groups handle which messaging groups, with what rules
 CREATE TABLE messaging_group_agents (
-  id                     TEXT PRIMARY KEY,
-  messaging_group_id     TEXT NOT NULL REFERENCES messaging_groups(id),
-  agent_group_id         TEXT NOT NULL REFERENCES agent_groups(id),
-  engage_mode            TEXT NOT NULL DEFAULT 'mention',  -- 'pattern' | 'mention' | 'mention-sticky'
-  engage_pattern         TEXT,                             -- regex; required for engage_mode='pattern'
-                                                           -- ('.' = match every message, the "always" flavor)
-  sender_scope           TEXT NOT NULL DEFAULT 'all',      -- 'all' | 'known'
-  ignored_message_policy TEXT NOT NULL DEFAULT 'drop',     -- 'drop' | 'accumulate'
-  session_mode           TEXT DEFAULT 'shared',            -- 'shared' | 'per-thread'
-  priority               INTEGER DEFAULT 0,                -- higher = checked first when multiple agents match
-  created_at             TEXT NOT NULL,
+  id                 TEXT PRIMARY KEY,
+  messaging_group_id TEXT NOT NULL REFERENCES messaging_groups(id),
+  agent_group_id     TEXT NOT NULL REFERENCES agent_groups(id),
+  trigger_rules      TEXT,              -- JSON: { pattern, mentionOnly, excludeSenders, includeSenders }
+  response_scope     TEXT DEFAULT 'all',    -- 'all' | 'triggered' | 'allowlisted'
+  session_mode       TEXT DEFAULT 'shared', -- 'shared' | 'per-thread'
+  priority           INTEGER DEFAULT 0,     -- higher = checked first when multiple agents match
+  created_at         TEXT NOT NULL,
   UNIQUE(messaging_group_id, agent_group_id)
 );
 
@@ -854,7 +795,7 @@ stopped → running → idle → stopped
 
 ## Agent-Runner Architecture
 
-The agent-runner is the process inside the container. It mediates between the session DB and the agent provider — polling for work, formatting messages for the agent, translating tool calls into DB rows, and managing the agent lifecycle.
+The agent-runner is the process inside the container. It mediates between the session DB and the Claude SDK — polling for work, formatting messages for the agent, translating tool calls into DB rows, and managing the agent lifecycle.
 
 ### IO Model
 
@@ -867,55 +808,50 @@ All IO goes through the session DB. No stdin, no stdout markers, no IPC files.
 
 ### Poll Loop
 
-1. Query `inbound.db` (read-only) for `messages_in WHERE status = 'pending' AND (process_after IS NULL OR process_after <= now())`, skipping any id already in `processing_ack`
-2. If rows found: upsert `processing_ack` rows with `status = 'processing'` in `outbound.db` (the container can't write `messages_in`)
+1. Query `messages_in WHERE status = 'pending' AND (process_after IS NULL OR process_after <= now())`
+2. If rows found: set `status = 'processing'`, `status_changed = now()` on each
 3. Batch messages into a single prompt (strip routing fields, format by kind)
-4. Push into the provider's input stream
+4. Push into Claude SDK's MessageStream
 5. Process agent output → write `messages_out` rows
-6. Set the processed ids' `processing_ack.status = 'completed'` (the host mirrors that onto `messages_in.status`)
+6. Set processed messages to `status = 'completed'`
 7. Back to step 1. If no messages found, sleep briefly and re-poll (container stays warm for idle timeout)
 
 ### Message Formatting by Kind
 
 Agent-runner strips routing fields (`platform_id`, `channel_type`, `thread_id`) before formatting. The agent never sees routing info — it only sees content.
 
-- **`chat`** — format into a `<message id="…" from="…" sender="…" time="…">` element
-- **`chat-sdk`** — extract text, author, attachments from serialized message; same `<message>` element
-- **`task`** — format as a `<task from="…" time="…">` element (script output first if present). Run pre-script if present.
-- **`webhook`** — format as a `<webhook source="…" event="…">` element wrapping the JSON payload
-- **`system`** — host action results, formatted as `<system_response action="…" status="…">`, not chat
+- **`chat`** — format into `<messages>` XML block
+- **`chat-sdk`** — extract text, author, attachments from serialized message; format into `<messages>` XML
+- **`task`** — format as `[SCHEDULED TASK]` prefix + prompt. Run pre-script if present.
+- **`webhook`** — format as `[WEBHOOK: source/event]` + JSON payload
+- **`system`** — host action results (e.g., "register_group succeeded"). Format as system context, not chat.
 
 Mixed batches (e.g., a chat message + a system result both pending) are combined into one prompt with clear delimiters.
 
 ### MCP Tools
 
-MCP tools write to the container's own `outbound.db`. Anything that needs a change in host-owned `inbound.db` (schedule/cancel/pause/resume/update a task, create an agent, self-modify) is emitted as a `kind: 'system'` `messages_out` action that the host applies during delivery — the container never writes `inbound.db`.
+MCP tools write to the container's own `outbound.db`. Anything that needs a change in host-owned `inbound.db` (schedule/cancel/pause/resume/update a task, register a group) is emitted as a `kind: 'system'` `messages_out` action that the host applies during delivery — the container never writes `inbound.db`.
 
-**Messaging & interaction:**
+**Core tools:**
 
 | Tool | What it does |
 |------|-------------|
-| `send_message` | Resolve `to` (destination name) → routing, write `messages_out` row, `kind: 'chat'`. Omit `to` to reply in place. Also the agent-to-agent path: a `to` naming an `agent`-type destination. |
-| `send_file` | Copy file to `outbox/{msg_id}/`, write `messages_out` (`kind: 'chat'`) with filenames, same `to` resolution |
-| `send_card` | Write `messages_out`, `kind: 'chat-sdk'`, content `{ type: 'card', … }` |
-| `ask_user_question` | Write `messages_out` (`kind: 'chat-sdk'`, `type: 'ask_question'`). Hold tool call open, poll `inbound.db` for the response matching `questionId`. Return selection as tool result. |
-| `edit_message` | Write `messages_out` with `operation: 'edit'` (targets the original message's destination) |
+| `send_message` | Write `messages_out` row, `kind: 'chat'` |
+| `send_file` | Move file to `outbox/{msg_id}/`, write `messages_out` with filenames |
+| `schedule_task` | Write `messages_out`, `kind: 'system'`, `action: 'schedule_task'`; host inserts the `kind: 'task'` `messages_in` row with `process_after` + optional `recurrence` |
+| `list_tasks` | Read `messages_in` (read-only mount) — one row per series: `kind = 'task' AND status IN ('pending','paused') GROUP BY series_id` |
+| `pause_task` / `resume_task` / `cancel_task` | Write `messages_out`, `kind: 'system'`, matching `action`; host updates the live `messages_in` row(s) |
+| `register_agent_group` | Write `messages_out`, `kind: 'system'`, `action: 'register_agent_group'` |
+
+**New tools:**
+
+| Tool | What it does |
+|------|-------------|
+| `ask_user_question` | Write `messages_out` with question card. Hold tool call open, poll `messages_in` for response matching `questionId`. Return selection as tool result. |
+| `edit_message` | Write `messages_out` with `operation: 'edit'` |
 | `add_reaction` | Write `messages_out` with `operation: 'reaction'` |
-
-(There is no `send_to_agent` tool — agent-to-agent is `send_message` to an `agent` destination.)
-
-**Scheduling**: scheduled-task management is not an MCP surface — it lives on
-`ncl tasks` (create/list/get/update/cancel/pause/resume/run/append-log). Due
-task rows live in the agent group's system session and are woken by the host
-sweep.
-
-**Central-DB / self-modification** (`kind: 'system'` actions; host authorizes, often via admin approval):
-
-| Tool | What it does |
-|------|-------------|
-| `create_agent` | `action: 'create_agent'` (name + instructions); host creates the agent group (replaces the old `register_agent_group`) |
-| `install_packages` | `action: 'install_packages'`; on approval host rebuilds the per-agent image and restarts |
-| `add_mcp_server` | `action: 'add_mcp_server'`; on approval host updates `container.json` and restarts |
+| `send_to_agent` | Write `messages_out` with `channel_type: 'agent'`, `platform_id: '{target}'` |
+| `send_card` | Write `messages_out` with card structure |
 
 See [agent-runner-details.md](agent-runner-details.md) for full MCP tool parameter definitions.
 
@@ -951,11 +887,11 @@ The command lists are hardcoded in the agent-runner. Admin verification happens
 
 The agent-runner processes recurring task messages like any other messages_in row. After the agent-runner marks a recurring message as `completed`, the **host** handles inserting the next occurrence (new messages_in row with `process_after` advanced to next cron time). The agent-runner doesn't manage recurrence — it just processes what it finds.
 
-Pre-scripts: if a task message has a `script` field, run it first. If `wakeAgent = false`, mark completed without invoking the provider.
+Pre-scripts: if a task message has a `script` field, run it first. If `wakeAgent = false`, mark completed without invoking Claude.
 
 ### Agent-to-Agent Messaging
 
-**Outbound:** Agent calls `send_message(to="<agent-name>")` where the named destination is of type `agent` → agent-runner writes messages_out with `channel_type: 'agent'`, `platform_id` = target agent group ID. Host validates permissions and writes to the target session's `inbound.db` (recording `source_session_id` so the reply routes back to this exact session).
+**Outbound:** Agent calls `send_to_agent` tool → agent-runner writes messages_out with `channel_type: 'agent'`, `platform_id` = target agent group ID. Host validates permissions and writes to target session's messages_in.
 
 **Inbound:** Messages from other agents arrive as normal `chat` messages_in rows. The content includes `sender` and `senderId` (e.g., `"senderId": "agent:pr-admin"`). No special formatting — the agent sees it as a chat message.
 
@@ -971,7 +907,7 @@ Pre-scripts: if a task message has a `script` field, run it first. If `wakeAgent
 
 - **Approval routing** — how does the host find the admin's DM conversation? What if no DM channel exists? Is the approval list configurable per agent group or global?
 - **MCP server lifecycle** — does the MCP server process persist across multiple queries in the same container, or restart each time?
-- **Container startup config** — what config (if any) is passed to the container at launch beyond env vars? The DB files are at fixed mount paths. System prompt comes from CLAUDE.md. Provider name comes from `container.json` (materialized from the `container_configs` table), not env. What else?
+- **Container startup config** — what config (if any) is passed to the container at launch beyond env vars? The session DB is at a fixed mount path. System prompt comes from CLAUDE.md. Provider name comes from env. What else?
 - **Idle detection with pending questions** — when `ask_user_question` is waiting for a response, the container should not be considered idle. Also need to detect when the agent is still working (active tool calls, subagents) and avoid killing the container even if no messages_out have been written recently.
 
 ## Related Documents

docs/build-and-runtime.md

@@ -33,13 +33,13 @@ Both are committed. CI and the Dockerfile run `--frozen-lockfile` variants — a
 ## Supply chain
 
 - **Host + global CLIs** (pnpm): `minimumReleaseAge: 4320` (3-day hold on new versions), `onlyBuiltDependencies` allowlist for postinstall scripts. See `pnpm-workspace.yaml` and `docs/SECURITY.md`.
-- **Agent-runner** (Bun): no release-age policy — Bun doesn't have an equivalent today. The defenses are `bun.lock` pinning plus a version-pinned Bun itself via a Dockerfile ARG (global CLIs are pinned separately in `container/cli-tools.json`). When bumping `@anthropic-ai/claude-agent-sdk` or any runtime dep, review the release date on npm and bump deliberately, not via `bun update`.
+- **Agent-runner** (Bun): no release-age policy — Bun doesn't have an equivalent today. The defenses are `bun.lock` pinning plus version-pinned CLIs/Bun itself via Dockerfile ARGs. When bumping `@anthropic-ai/claude-agent-sdk` or any runtime dep, review the release date on npm and bump deliberately, not via `bun update`.
 
 ## Image build surface
 
 `container/Dockerfile` is a single-stage build on `node:22-slim`:
 
-- **Pinned ARGs** — `BUN_VERSION`, `PNPM_VERSION`, `INSTALL_CJK_FONTS`. Bump deliberately in PRs. Global CLI versions (`@anthropic-ai/claude-code`, `agent-browser`, `vercel`) are pinned separately in `container/cli-tools.json`, not as ARGs.
+- **Pinned ARGs** — `BUN_VERSION`, `CLAUDE_CODE_VERSION`, `AGENT_BROWSER_VERSION`, `VERCEL_VERSION`. Bump deliberately in PRs.
 - **CJK fonts** — `ARG INSTALL_CJK_FONTS=false`. `container/build.sh` reads `INSTALL_CJK_FONTS` from `.env` and passes it through. Default build saves ~200MB; opt in when the user works with Chinese/Japanese/Korean content.
 - **BuildKit cache mounts** — `/var/cache/apt`, `/var/lib/apt`, `/root/.bun/install/cache`, `/root/.cache/pnpm`. Rebuilds where `package.json`/`bun.lock` haven't changed are fast. Requires BuildKit (default on Docker 23+, Apple Container-compat).
 - **`tini` as init** — reaps Chromium zombies, forwards signals so in-flight `outbound.db` writes finalize on SIGTERM.
@@ -49,7 +49,7 @@ Both are committed. CI and the Dockerfile run `--frozen-lockfile` variants — a
 ## Session wake (two paths)
 
 1. **Base image ENTRYPOINT** — used for stdin-piped test invocations like the sample in `container/build.sh`: `tini --> entrypoint.sh` captures stdin to `/tmp/input.json`, then `exec bun run src/index.ts`.
-2. **Host-spawned session** — `src/container-runner.ts` at line ~503 uses `--entrypoint bash` with `-c 'exec bun run /app/src/index.ts'`. Bypasses tini (Docker's default PID 1 handling applies). Stdin is unused; all IO flows through the mounted session DBs.
+2. **Host-spawned session** — `src/container-runner.ts` at line ~301 uses `--entrypoint bash` with `-c 'exec bun run /app/src/index.ts'`. Bypasses tini (Docker's default PID 1 handling applies). Stdin is unused; all IO flows through the mounted session DBs.
 
 Both paths end with Bun running the same source file from `/app/src/index.ts`.
 

docs/db-central.md

@@ -2,7 +2,7 @@
 
 Complete reference for `data/v2.db`, the host-owned admin-plane database. Start with [db.md](db.md) for the three-DB overview, the map, and the cross-mount rules.
 
-Access layer: `src/db/`. `src/db/schema.ts`'s `SCHEMA` constant is a *reference copy* of the core tables for orientation — it is not exhaustive: several tables (`agent_destinations`, `pending_approvals`, `container_configs`, `agent_message_policies`, `pending_channel_approvals`, and others) exist only in their migration files under `src/db/migrations/`, which remain the actual source of truth for what's created at runtime.
+Access layer: `src/db/`. Authoritative schema reference: `src/db/schema.ts` (comments only — actual creation runs via migrations in `src/db/migrations/`).
 
 ---
 
@@ -55,24 +55,20 @@ Wiring: which agent group handles which messaging group. Many-to-many — the sa
 
 ```sql
 CREATE TABLE messaging_group_agents (
-  id                     TEXT PRIMARY KEY,
-  messaging_group_id     TEXT NOT NULL REFERENCES messaging_groups(id),
-  agent_group_id         TEXT NOT NULL REFERENCES agent_groups(id),
-  engage_mode            TEXT NOT NULL DEFAULT 'mention',
-                         -- 'pattern' | 'mention' | 'mention-sticky'
-  engage_pattern         TEXT,   -- regex; required when engage_mode='pattern';
-                                 -- '.' means "match every message"
-  sender_scope           TEXT NOT NULL DEFAULT 'all',    -- 'all' | 'known'
-  ignored_message_policy TEXT NOT NULL DEFAULT 'drop',   -- 'drop' | 'accumulate'
-  session_mode           TEXT DEFAULT 'shared',
-  priority               INTEGER DEFAULT 0,
-  created_at             TEXT NOT NULL,
+  id                 TEXT PRIMARY KEY,
+  messaging_group_id TEXT NOT NULL REFERENCES messaging_groups(id),
+  agent_group_id     TEXT NOT NULL REFERENCES agent_groups(id),
+  trigger_rules      TEXT,
+  response_scope     TEXT DEFAULT 'all',
+  session_mode       TEXT DEFAULT 'shared',
+  priority           INTEGER DEFAULT 0,
+  created_at         TEXT NOT NULL,
   UNIQUE(messaging_group_id, agent_group_id)
 );
 ```
 
 - `session_mode`: `shared` (one session per channel), `per-thread` (one per thread), `agent-shared` (one per agent group across all channels).
-- `engage_mode` / `engage_pattern` / `sender_scope` / `ignored_message_policy`: four orthogonal axes (migration 010) that replaced v1's opaque `trigger_rules` JSON + `response_scope` enum. `engage_mode='pattern'` requires `engage_pattern` (`'.'` matches every message — the "always respond" flavor); `sender_scope='known'` restricts engagement to group members; `ignored_message_policy='accumulate'` keeps ignored messages as context instead of dropping them.
+- `trigger_rules`: JSON; e.g. regex for native channels.
 - **Side effect:** creating a wiring must also populate `agent_destinations` — don't mutate one without the other (see §1.10).
 
 ### 1.4 `users`
@@ -327,71 +323,6 @@ CREATE TABLE container_configs (
 - **Readers:** `src/container-config.ts`, `src/container-runner.ts`, `src/cli/dispatch.ts` (scope enforcement), `src/claude-md-compose.ts`
 - **Writers:** `src/db/container-configs.ts`, `src/modules/self-mod/apply.ts`, `src/backfill-container-configs.ts`
 
-### 1.16 `pending_sender_approvals`
-
-In-flight state for the `unknown_sender_policy = 'request_approval'` flow. A row exists while an admin-approval card is outstanding for a first-time sender in a wired messaging group; `UNIQUE(messaging_group_id, sender_identity)` dedups concurrent attempts from the same sender instead of spamming the admin with repeat cards.
-
-```sql
-CREATE TABLE pending_sender_approvals (
-  id                 TEXT PRIMARY KEY,
-  messaging_group_id TEXT NOT NULL REFERENCES messaging_groups(id),
-  agent_group_id     TEXT NOT NULL REFERENCES agent_groups(id),
-  sender_identity    TEXT NOT NULL,    -- namespaced user id (channel_type:handle)
-  sender_name        TEXT,
-  original_message   TEXT NOT NULL,    -- JSON of the original InboundEvent
-  approver_user_id   TEXT NOT NULL,
-  created_at         TEXT NOT NULL,
-  title              TEXT NOT NULL DEFAULT '',       -- added by migration 013
-  options_json       TEXT NOT NULL DEFAULT '[]',     -- added by migration 013
-  UNIQUE(messaging_group_id, sender_identity)
-);
-```
-
-Deleted on admin approve (after adding the sender as a member) or deny.
-
-- Access layer: `src/modules/permissions/db/pending-sender-approvals.ts`
-- **Readers/writers:** `src/modules/permissions/sender-approval.ts`, `src/modules/permissions/index.ts`, `src/db/sessions.ts` (`getAskQuestionRender`), `src/cli/resources/groups.ts`
-
-### 1.17 `pending_channel_approvals`
-
-In-flight state for the unknown-channel registration flow. When a channel with no `messaging_group_agents` wiring receives a mention or DM, the router escalates to the owner; `PRIMARY KEY(messaging_group_id)` gives free in-flight dedup via `INSERT OR IGNORE` — a second mention while a card is pending drops silently.
-
-```sql
-CREATE TABLE pending_channel_approvals (
-  messaging_group_id TEXT PRIMARY KEY REFERENCES messaging_groups(id),
-  agent_group_id     TEXT NOT NULL REFERENCES agent_groups(id),
-                     -- agent the approved wiring will target (earliest
-                     -- agent_group by created_at, picked at request time)
-  original_message   TEXT NOT NULL,      -- JSON of the original InboundEvent
-  approver_user_id   TEXT NOT NULL,
-  created_at         TEXT NOT NULL,
-  title              TEXT NOT NULL DEFAULT '',       -- added by migration 013
-  options_json       TEXT NOT NULL DEFAULT '[]'      -- added by migration 013
-);
-```
-
-Approve creates the `messaging_group_agents` wiring and replays the triggering event; deny sets `messaging_groups.denied_at` so future messages on that channel drop without re-prompting. Either way, this row is deleted.
-
-- Access layer: `src/modules/permissions/db/pending-channel-approvals.ts`
-- **Readers/writers:** `src/modules/permissions/channel-approval.ts`, `src/modules/permissions/index.ts`, `src/router.ts`, `src/db/sessions.ts` (`getAskQuestionRender`), `src/cli/resources/groups.ts`
-
-### 1.18 `agent_message_policies`
-
-Per-message approval gate on an agent-to-agent connection between two agent groups. No row for a `(from, to)` pair means free flow (no approval required); a row names the `approver` who must sign off on each message.
-
-```sql
-CREATE TABLE agent_message_policies (
-  from_agent_group_id TEXT NOT NULL REFERENCES agent_groups(id),
-  to_agent_group_id   TEXT NOT NULL REFERENCES agent_groups(id),
-  approver            TEXT NOT NULL,
-  created_at          TEXT NOT NULL,
-  PRIMARY KEY (from_agent_group_id, to_agent_group_id)
-);
-```
-
-- Access layer: `src/modules/agent-to-agent/db/agent-message-policies.ts`
-- **Readers/writers:** `src/cli/resources/policies.ts`; approved messages create a row in `pending_approvals` (see §1.11) via the a2a send path.
-
 ---
 
 ## 2. Migration system
@@ -399,33 +330,21 @@ CREATE TABLE agent_message_policies (
 Migrations live in `src/db/migrations/`, one file per migration. Runner: `runMigrations()` in `src/db/migrations/index.ts`. It:
 
 1. Creates `schema_version` if absent.
-2. Reads every already-applied `name` from `schema_version` into a `Set` and filters the `migrations` barrel array down to the ones whose `name` isn't in that set — dedup is by **name**, not by the numeric `version` field.
-3. Runs each pending migration's `up(db)` inside a transaction, in the barrel array's literal order (which is *not* sorted by `version`), then inserts a `schema_version` row.
-4. The `version` column stored in `schema_version` is **not** the migration's own `version` field — it's `COALESCE(MAX(version), 0) + 1`, i.e. an auto-assigned applied-order number computed at insert time. The `version` field on the `Migration` object is just an ordering hint for humans reading the barrel file; it lets module migrations (installed later by skills) pick arbitrary numbers without coordinating with trunk.
+2. Reads `MAX(version)` — call it `current`.
+3. For each migration with `version > current`, executes `up(db)` inside a transaction and appends a `schema_version` row.
 
-A few migrations also set `disableForeignKeys: true` (needed for table recreates — SQLite can't relax a table-level `UNIQUE` without DROP+RENAME, which fails FK integrity checks with live child rows). The runner toggles `PRAGMA foreign_keys` around the transaction and runs `PRAGMA foreign_key_check` inside it, snapshotting pre-existing violations so it only fails on violations the migration itself introduced.
+| # | File | Introduces |
+|---|------|------------|
+| 001 | `001-initial.ts` | Core tables: `agent_groups`, `messaging_groups`, `messaging_group_agents`, `users`, `user_roles`, `agent_group_members`, `user_dms`, `sessions`, `pending_questions` |
+| 002 | `002-chat-sdk-state.ts` | `chat_sdk_kv`, `chat_sdk_subscriptions`, `chat_sdk_locks`, `chat_sdk_lists` |
+| 003 | `003-pending-approvals.ts` | `pending_approvals` (session-bound + OneCLI fields) |
+| 004 | `004-agent-destinations.ts` | `agent_destinations` + backfill from existing `messaging_group_agents` wirings |
+| 007 | `007-pending-approvals-title-options.ts` | `ALTER TABLE pending_approvals` add `title`, `options_json` (retrofits DBs created between 003 and 007) |
+| 008 | `008-dropped-messages.ts` | `unregistered_senders` |
+| 009 | `009-drop-pending-credentials.ts` | Drop the defunct `pending_credentials` table |
+| 014 | `014-container-configs.ts` | `container_configs` — per-agent-group container runtime config |
+| 015 | `015-cli-scope.ts` | `ALTER TABLE container_configs ADD COLUMN cli_scope` |
 
-Several early migrations were later renamed/retired and replaced by "module" files (their original `name` is retained on the new file so already-migrated DBs don't re-run them):
-
-| Ver. | Name (stored in `schema_version`) | File | Introduces |
-|---|---|------|------------|
-| 1 | `initial-v2-schema` | `001-initial.ts` | Core tables: `agent_groups`, `messaging_groups`, `messaging_group_agents` (with the original `trigger_rules`/`response_scope` columns — see v10), `users`, `user_roles`, `agent_group_members`, `user_dms`, `sessions`, `pending_questions` |
-| 2 | `chat-sdk-state` | `002-chat-sdk-state.ts` | `chat_sdk_kv`, `chat_sdk_subscriptions`, `chat_sdk_locks`, `chat_sdk_lists` |
-| 3 | `pending-approvals` | `module-approvals-pending-approvals.ts` | `pending_approvals` (session-bound + OneCLI fields) |
-| 4 | `agent-destinations` | `module-agent-to-agent-destinations.ts` | `agent_destinations` + backfill from existing `messaging_group_agents` wirings |
-| 7 | `pending-approvals-title-options` | `module-approvals-title-options.ts` | Retroactive `ALTER TABLE pending_approvals` add `title`, `options_json` for DBs that ran migration 3 before its `CREATE TABLE` was edited to include those columns |
-| 8 | `dropped-messages` | `008-dropped-messages.ts` | `unregistered_senders` |
-| 9 | `drop-pending-credentials` | `009-drop-pending-credentials.ts` | Drop the defunct `pending_credentials` table |
-| 10 | `engage-modes` | `010-engage-modes.ts` | `messaging_group_agents`: add `engage_mode`, `engage_pattern`, `sender_scope`, `ignored_message_policy`; backfill from `trigger_rules`/`response_scope`; drop those two legacy columns (see §1.3) |
-| 11 | `pending-sender-approvals` | `011-pending-sender-approvals.ts` | `pending_sender_approvals` (see §1.16) |
-| 12 | `channel-registration` | `012-channel-registration.ts` | `messaging_groups.denied_at` + `pending_channel_approvals` (see §1.17) |
-| 13 | `approval-render-metadata` | `013-approval-render-metadata.ts` | `title`, `options_json` columns on `pending_channel_approvals` and `pending_sender_approvals` |
-| 14 | `container-configs` | `014-container-configs.ts` | `container_configs` — per-agent-group container runtime config |
-| 15 | `cli-scope` | `015-cli-scope.ts` | `ALTER TABLE container_configs ADD COLUMN cli_scope` |
-| 16 | `messaging-group-instance` | `016-messaging-group-instance.ts` | `messaging_groups` gets an `instance` column (adapter-instance dimension); table recreate (`disableForeignKeys: true`) backfills `instance = channel_type` on every existing row and relaxes the `UNIQUE` to `(channel_type, platform_id, instance)` |
-| 17 | `agent-message-policies` | `017-agent-message-policies.ts` | `agent_message_policies` (see §1.18) |
-| 18 | `approvals-approver-user-id` | `018-approvals-approver-user-id.ts` | `pending_approvals.approver_user_id` — names a single required approver for a2a message-gate policies |
-
-Numbers 5 and 6 are intentionally absent — migrations were renumbered during early development.
+Numbers 005 and 006 are intentionally absent — migrations were renumbered during early development.
 
 Session DB schemas (`INBOUND_SCHEMA`, `OUTBOUND_SCHEMA`) are **not** versioned here. They're `CREATE TABLE IF NOT EXISTS` so new columns land via the session-DB lazy migration helpers (`migrateDeliveredTable()` etc.) when a session file from an older build is reopened. See [db-session.md](db-session.md).

docs/db-session.md

@@ -10,15 +10,13 @@ Schemas live in `src/db/schema.ts` as the `INBOUND_SCHEMA` and `OUTBOUND_SCHEMA`
 
 ```
 data/v2-sessions/<agent_group_id>/<session_id>/
-  inbound.db              ← host writes, container reads (read-only open)
+  inbound.db              ← host writes, container reads (read-only mount)
   outbound.db             ← container writes, host reads (read-only open)
   .heartbeat              ← mtime touched by container (not a DB write)
   inbox/<message_id>/     ← user attachments, decoded from inbound message content
   outbox/<message_id>/    ← attachments the agent produced
 ```
 
-The session directory itself is mounted read-write into the container (`src/container-runner.ts`) — read-only is *not* a mount property. The container opens `inbound.db` with `{ readonly: true }` at the SQLite connection layer (`container/agent-runner/src/db/connection.ts`), so the container could technically write to the underlying file via another path, but every code path that touches `inbound.db` from inside the container goes through that read-only handle.
-
 One session = one folder = one pair of DBs. The `agent_group_id` parent directory also holds per-group state (`.claude-shared/`) that is shared across every session of that agent group. (The agent-runner source is not copied per group — it's a shared read-only mount from `container/agent-runner/src` into every container; see `src/container-runner.ts`.)
 
 Path helpers in `src/session-manager.ts`: `sessionDir()`, `inboundDbPath()`, `outboundDbPath()`, `heartbeatPath()`.
@@ -179,24 +177,6 @@ CREATE TABLE session_state (
 
 Access: `container/agent-runner/src/db/session-state.ts`.
 
-### 4.4 `container_state`
-
-Single-row (`id=1`) tool-in-flight tracker. The container records the currently-running tool on `PreToolUse` and clears it on `PostToolUse`/`PostToolUseFailure`; the host reads it during the stale-container sweep to widen its stuck-tolerance window when `Bash` is running with a user-declared `timeout` over the normal threshold, so long-running scripts aren't killed as "stuck".
-
-```sql
-CREATE TABLE container_state (
-  id                       INTEGER PRIMARY KEY CHECK (id = 1),
-  current_tool             TEXT,
-  tool_declared_timeout_ms INTEGER,
-  tool_started_at          TEXT,
-  updated_at               TEXT NOT NULL
-);
-```
-
-- **Writer (container):** `setContainerToolInFlight()` / `clearContainerToolInFlight()` in `container/agent-runner/src/db/connection.ts`, called from the `preToolUseHook` / `postToolUseHook` in `container/agent-runner/src/providers/claude.ts`.
-- **Reader (host):** `getContainerState()` in `src/db/session-db.ts`; consumed by the sweep's `bashTimeoutMs()` helper in `src/host-sweep.ts`.
-- `CREATE TABLE IF NOT EXISTS` — forward-compatible with `outbound.db` files created before this table existed; `getContainerState()` returns `null` if the table or row is absent.
-
 ---
 
 ## 5. Schema evolution

docs/isolation-model.md

@@ -80,11 +80,9 @@ agent_groups (workspace, memory, CLAUDE.md, personality)
     ↕ many-to-many
 messaging_groups (a specific channel/chat/group on a platform)
     via
-messaging_group_agents (session_mode, engage_mode, engage_pattern, sender_scope, ignored_message_policy, priority, threads)
+messaging_group_agents (session_mode, trigger_rules, priority)
 ```
 
-Wiring-creation defaults for engage mode/pattern, thread policy, and unknown-sender policy come from the channel adapter's declaration (per DM/group context), overridable per wiring at creation — see [setup-wiring.md](setup-wiring.md#channel-defaults-two-level-model) and [api-details.md](api-details.md#channel-defaults).
-
 - **Shared session:** multiple messaging_groups → same agent_group, `session_mode = 'agent-shared'`
 - **Same agent, separate sessions:** multiple messaging_groups → same agent_group, `session_mode = 'shared'`
 - **Separate agents:** each messaging_group → different agent_group

docs/ncl-tasks-migration.md

@@ -1,52 +0,0 @@
-# `ncl tasks` migration
-
-## Detect
-
-If an agent mentions `schedule_task`, `list_tasks`, `update_task`, `cancel_task`, `pause_task`, or `resume_task`, it is using the old scheduling MCP surface.
-
-A subtler symptom of a stale container image: the agent reports a task as scheduled, but `ncl tasks list` shows nothing and the host log has `Unknown system action` — the old image's `schedule_task` call is acknowledged in-container and then dropped by the new host. The fix below (rebuild + restart) resolves it.
-
-## Why
-
-Scheduling moved to `ncl tasks`. New tasks are stored in a per-agent-group system session and run there, so a scheduled task does not wake an existing chat session. When it fires, the agent must choose the delivery destination explicitly.
-
-## Fix
-
-Rebuild and restart agent containers so they load the updated MCP tool list and instructions:
-
-```bash
-./container/build.sh
-launchctl kickstart -k gui/$(id -u)/com.nanoclaw
-```
-
-On Linux, restart with `systemctl --user restart nanoclaw`.
-
-Use:
-
-```bash
-ncl tasks list
-ncl tasks create --group <agent_group_id> --prompt "..." --process-after "2026-01-15T09:00:00" --recurrence "0 9 * * *"
-ncl tasks update --id <series_id> --prompt "..."
-ncl tasks cancel --id <series_id>
-```
-
-## Verify
-
-Run `ncl tasks list`. New task rows should show a system `session_id`, not the chat session that requested the task.
-
-## Legacy tasks (scheduled before this update)
-
-Tasks created through the old MCP tools live in the **chat session** that created them, not in a per-series system session. They are unaffected by this update: they keep firing and delivering exactly as before. Two things to know:
-
-- An agent's own `ncl tasks list` (group scope) shows only its group's task rows; from the **host**, unscoped `ncl tasks list` enumerates everything, and `--session <id>` narrows to one session — that is how you find and manage legacy rows (`ncl tasks cancel --session <chat_session_id> --all` to clear a chat session's tasks).
-- The `messages_in` status enum now includes `cancelled` (cancel marks the row and clears its recurrence rather than deleting it). Custom code that exhaustively switches on task status needs the new arm.
-
-## Rollback
-
-Order matters:
-
-1. Remove tasks created through `ncl tasks` (`ncl tasks list` / `delete`) — they live in per-series system sessions the old code doesn't know about.
-2. **Wait one sweep (≤60s)** so the host closes the now-empty task sessions.
-3. Then revert the update and rebuild the container image.
-
-Reverting before the task sessions are collected leaves system sessions behind that the old `findSessionByAgentGroup` (which has no system-session exclusion) can resolve as the group's session — mis-routing agent-to-agent messages into a dead task thread.

docs/onecli-upgrades.md

@@ -10,11 +10,11 @@ Find out what is running and what is required:
 
 ```bash
 cat versions.json                                   # the sanctioned pin
-curl -s http://127.0.0.1:10254/api/health           # liveness check; `version` field is typically "unknown", not the gateway version
+curl -s http://127.0.0.1:10254/api/health           # reports the running gateway version
 curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:10254/v1/health
 ```
 
-If the last command prints `404`, the server predates the `/v1` API that `@onecli-sh/sdk` 2.x requires — every SDK call will fail with 404s that look transient but are permanent. If your gateway is remote, substitute its host for `127.0.0.1` (it's `ONECLI_URL` in `.env`; `NANOCLAW_ONECLI_API_HOST` is a setup-time override only, not persisted to `.env`).
+If the last command prints `404`, the server predates the `/v1` API that `@onecli-sh/sdk` 2.x requires — every SDK call will fail with 404s that look transient but are permanent. If your gateway is remote, substitute its host for `127.0.0.1` (it's in `.env` as `ONECLI_URL` / `NANOCLAW_ONECLI_API_HOST`).
 
 Why gateways fall behind: the OneCLI installer's docker-compose tracks the `latest` image tag, but Docker never re-pulls a tag — the server freezes at whatever `latest` meant on install day.
 

docs/setup-flow.md

@@ -179,7 +179,7 @@ So during this step:
   marker.
 
 The level-2 log still gets an entry (`auth [interactive] → success`
-with the method — subscription / oauth / api). Level-3 captures
+with the method — subscription / oauth-token / api-key). Level-3 captures
 are optional here; mirroring `script -q` output is tricky and the risk of
 leaking the token to disk outweighs the debugging value.
 
@@ -190,7 +190,7 @@ leaking the token to disk outweighs the debugging value.
 | `nanoclaw.sh` | Top-level wrapper. Phase 1 (bootstrap) and phase 2 (setup:auto) orchestration. Writes bootstrap's raw log + progression entry. `--uninstall` bypasses bootstrap entirely — it execs setup:auto directly (the flow lives in `setup/uninstall/`), or prints manual-cleanup guidance and exits 1 when the TS toolchain is missing. |
 | `setup.sh` | Phase 1 bootstrap: Node, pnpm, native-module verify. Emits its own `BOOTSTRAP` status block (historically printed to stdout; now goes to the bootstrap raw log). |
 | `setup/auto.ts` | Phase 2 driver. Orchestrates the clack UI, step execution, user prompts, and writes to all three log levels for every step it spawns. |
-| `setup/logs.ts` | The logging primitives (`step`, `userInput`, `complete`, `stepRawLog`, `reset`). Single source of truth for level 2/3 formatting and file paths. |
+| `setup/logs.ts` | The logging primitives (`logStep`, `logUserInput`, `logComplete`, `stepRawLog`, `initSetupLog`). Single source of truth for level 2/3 formatting and file paths. |
 | `setup/<step>.ts` | Individual step implementations. Must emit one terminal status block; must not write directly to the terminal. |
 | `setup/register-claude-token.sh` | The Anthropic exception. Inherits stdio, prints its own UI, returns a status to the driver. |
 | `setup/add-telegram.sh` | Non-interactive adapter installer. Reads `TELEGRAM_BOT_TOKEN` from env; never prompts. User-facing bits live in `auto.ts`. |

docs/setup-wiring.md

@@ -1,6 +1,6 @@
 # Setup Wiring — Status & Remaining Work
 
-Last updated: 2026-07-10
+Last updated: 2026-04-09
 
 ## What's Done
 
@@ -14,7 +14,7 @@ Last updated: 2026-07-10
 - Container clears stale `processing_ack` entries on startup (crash recovery)
 - Files: `src/db/schema.ts` (INBOUND_SCHEMA + OUTBOUND_SCHEMA), `src/session-manager.ts`, `src/delivery.ts`, `src/host-sweep.ts`, `container/agent-runner/src/db/connection.ts`, `messages-in.ts`, `messages-out.ts`, `poll-loop.ts`, `mcp-tools/scheduling.ts`, `mcp-tools/interactive.ts`
 - Container image rebuilt with tsconfig (`container/agent-runner/tsconfig.json`)
-- E2E verified: host → Docker container → agent responds → "E2E works!" ✓
+- E2E verified: host → Docker container → Claude responds → "E2E works!" ✓
 
 ### OneCLI Integration
 - `ensureAgent()` call added before `applyContainerConfig()` in `src/container-runner.ts`
@@ -35,19 +35,6 @@ Last updated: 2026-07-10
 ### Router Logging
 - `src/router.ts` logs `MESSAGE DROPPED` at WARN level when no agents wired, with actionable guidance
 
-### Channel Defaults (two-level model)
-
-Each adapter declares its own wiring-time defaults (`ChannelDefaults`, see [api-details.md](api-details.md#channel-defaults)): per-context (DM vs group) engage mode, engage pattern, thread policy, and unknown-sender policy, plus how the platform signals mentions (`'platform' | 'dm-only' | 'never'`). Exactly two levels exist:
-
-1. **Adapter declaration** — a static const in the adapter module (and its `ChannelRegistration`, so offline scripts resolve it without credentials). Adapters are skill-installed and user-owned; install-wide changes mean editing the adapter copy. No DB config table.
-2. **Per-wiring override** — the explicit value chosen at creation (`ncl` flag, wizard answer, card-flow value), stored on the row. Existing rows are never re-resolved; declarations are consulted only at creation, except threading, which stays live via `messaging_group_agents.threads` (`NULL` = inherit).
-
-All creation paths (`ncl wirings`/`messaging-groups`, `setup/register.ts`, the router's auto-create, the channel-approval card flow, bootstrap scripts) go through the shared helpers in `src/channels/channel-defaults.ts`, so a platform's defaults are declared once and apply everywhere.
-
-**Shared-identity pattern.** When the platform identity the adapter connects as belongs to a human (WhatsApp shared-number mode: `ASSISTANT_HAS_OWN_NUMBER` unset), the adapter itself suppresses mention signals — it never sets `isMention` and declares `mentions: 'never'`, group defaults of a name-pattern (`\b{name}\b`) and `strict` sender policy. With no mention signal, the router never auto-creates messaging groups or fires approval cards for the human's own conversations — the spam dies at the source, with zero core conditionals. The pattern is entirely channel-local and reusable by any adapter riding a personal identity (iMessage, Signal) with no core involvement.
-
-**Back-compat contract.** A trunk update alone changes no behavior: stale (undeclared) adapters resolve through a behavior-faithful fallback at runtime, `ncl` keeps its legacy static defaults for them (gated on `hasDeclaredChannelDefaults`), existing DB rows are untouched, and the new `threads` column ships `NULL` everywhere — which reproduces today's `supportsThreads`-derived routing exactly. Updating an adapter copy (via its `/add-<channel>` skill) is what opts an install into that channel's new defaults, and even then only for wirings created afterwards. The one deliberate exception is the isGroup bugfix: card-approved groups on non-threaded platforms now wire via the group default instead of pattern `'.'` (group-ness comes from `event.message.isGroup ?? mg.is_group`, never `threadId !== null`).
-
 ---
 
 ## Previously Open — Now Resolved
@@ -78,11 +65,11 @@ Added `session_mode: 'agent-shared'` for cross-channel shared sessions (e.g. Git
 
 ### Entity Model
 ```
-agent_groups (id, name, folder, agent_provider)
-    ↕ many-to-many                       (container runtime config lives in the separate container_configs table)
-messaging_groups (id, channel_type, platform_id, instance, name, is_group, unknown_sender_policy, denied_at)
+agent_groups (id, name, folder, agent_provider, container_config)
+    ↕ many-to-many
+messaging_groups (id, channel_type, platform_id, name, is_group, unknown_sender_policy)
     via
-messaging_group_agents (messaging_group_id, agent_group_id, engage_mode, engage_pattern, sender_scope, ignored_message_policy, session_mode, priority, threads)
+messaging_group_agents (messaging_group_id, agent_group_id, trigger_rules, session_mode, priority)
 
 users (id, kind, display_name)          -- namespaced as "<channel>:<handle>"
 user_roles (user_id, role, agent_group_id)    -- owner / admin (global or scoped)

docs/templates.md

@@ -2,21 +2,27 @@
 
 A **template** is a reusable folder you stamp into a working agent group: it
 carries the agent's standing instructions, its MCP tool servers, and its skills,
-but **no secrets and no provider**. Point `ncl` at one and
+but **no secrets and no provider**. Point `ncl` (or the setup wizard) at one and
 you get a configured agent in seconds; you choose the runtime/provider
 separately.
 
-Templates are purely additive: no DB migration, no new dependency. **Templates
-are resolved only from a local directory**: `templates/` at the
+Templates are purely additive: no DB migration, no new dependency. **At runtime,
+templates are resolved only from a local directory**: `templates/` at the
 project root by default (committed but shipped empty), or whatever
-`NANOCLAW_TEMPLATES_DIR` points at (a local path only). The public registry
+`NANOCLAW_TEMPLATES_DIR` points at (a local path only). The setup wizard can also
+discover templates from the public registry
 ([`nanocoai/nanoclaw-templates`](https://github.com/nanocoai/nanoclaw-templates))
-is a manual copy source — clone or download it yourself and copy the chosen
-template into your local `templates/` before stamping.
+and copy a chosen one into your local `templates/` before stamping.
 
 ## Using a template
 
-**Via the CLI:**
+**During install.** `bash nanoclaw.sh` opens the setup wizard. Choose **Template
+setup**, then either **NanoClaw template library** (clones the public registry,
+copies the template you pick into your local `templates/`) or **Local templates**
+(lists what's already in `templates/`). The normal auth step then picks the
+runtime, and the wizard stamps and wires your first agent.
+
+**Anytime, via the CLI:**
 
 ```bash
 ncl groups create --template sales/sdr --name "SDR Agent"
@@ -34,8 +40,8 @@ e.g. `sales/sdr` → `templates/sales/sdr`.
 
 For safety the ref must stay inside the templates directory: absolute paths, a
 leading `~`, and `../` escapes are rejected. There is no `--source`, no git URL,
-and no remote fetch at `ncl` time. Populate `templates/` first (by hand, e.g.
-copying from the public registry), then stamp.
+and no remote fetch at `ncl` time. Populate `templates/` first (by hand, or via
+the setup wizard's library option), then stamp.
 
 `NANOCLAW_TEMPLATES_DIR` may point the library at another **local** directory; it
 is never a URL and never changes at runtime.

docs/v1-to-v2-changes.md

@@ -80,7 +80,7 @@ Tasks can exist before a session is awake — the host sweep creates/wakes the c
 
 **v2:** OneCLI Agent Vault. A separate local service at `http://127.0.0.1:10254` holds secrets. Agents are *scoped* to specific secrets and the vault injects them into approved API requests as they leave the container. The container never sees the raw secret value.
 
-Note: auto-created agents default to `all` secret mode — every vault secret whose host pattern matches is injected automatically. See the "Secret modes" section of the root CLAUDE.md if you want per-agent control (`onecli agents set-secret-mode --mode selective`).
+Gotcha: auto-created agents default to `selective` secret mode — no secrets attached, even if matching secrets exist in the vault. See the "auto-created agents start in selective secret mode" section of the root CLAUDE.md for the fix (`onecli agents set-secret-mode --mode all`).
 
 **What the automated migration does:** copies every v1 `.env` key verbatim into v2 `.env`, never overwriting existing v2 keys. The OneCLI vault migration is a separate step owned by the `/init-onecli` skill, which knows how to pull from `.env`.
 

package.json

@@ -1,6 +1,6 @@
 {
   "name": "nanoclaw",
-  "version": "2.1.46",
+  "version": "2.1.38",
   "description": "Personal Claude assistant. Lightweight, secure, customizable.",
   "type": "module",
   "packageManager": "pnpm@10.33.0",

repo-tokens/badge.svg

@@ -1,5 +1,5 @@
-<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="90" height="20" role="img" aria-label="232k tokens, 116% of context window">
-  <title>232k tokens, 116% of context window</title>
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="90" height="20" role="img" aria-label="208k tokens, 104% of context window">
+  <title>208k tokens, 104% of context window</title>
   <linearGradient id="s" x2="0" y2="100%">
     <stop offset="0" stop-color="#bbb" stop-opacity=".1"/>
     <stop offset="1" stop-opacity=".1"/>
@@ -15,8 +15,8 @@
       <g fill="#fff" text-anchor="middle" font-family="Verdana,Geneva,DejaVu Sans,sans-serif" font-size="11">
         <text aria-hidden="true" x="26" y="15" fill="#010101" fill-opacity=".3">tokens</text>
         <text x="26" y="14">tokens</text>
-        <text aria-hidden="true" x="71" y="15" fill="#010101" fill-opacity=".3">232k</text>
-        <text x="71" y="14">232k</text>
+        <text aria-hidden="true" x="71" y="15" fill="#010101" fill-opacity=".3">208k</text>
+        <text x="71" y="14">208k</text>
       </g>
     </g>
   </a>

scripts/init-cli-agent.ts

@@ -10,8 +10,7 @@
  * CLAUDE.md.
  *
  * Runs alongside the service (WAL-mode sqlite) — does NOT initialize
- * channel adapters, so there's no Gateway conflict. (The channels barrel
- * import below only registers factories + declarations; nothing connects.)
+ * channel adapters, so there's no Gateway conflict.
  *
  * Usage:
  *   pnpm exec tsx scripts/init-cli-agent.ts \
@@ -20,13 +19,6 @@
  */
 import path from 'path';
 
-// Registration-only: makes the in-tree cli adapter's declared defaults
-// (pattern '.', no threads, 'public') resolvable below.
-import '../src/channels/index.js';
-import {
-  resolveUnknownSenderPolicy,
-  resolveWiringDefaults,
-} from '../src/channels/channel-defaults.js';
 import { DATA_DIR } from '../src/config.js';
 import { createAgentGroup, getAgentGroupByFolder } from '../src/db/agent-groups.js';
 import { updateContainerConfigScalars } from '../src/db/container-configs.js';
@@ -147,9 +139,7 @@ async function main(): Promise<void> {
       platform_id: CLI_PLATFORM_ID,
       name: 'Local CLI',
       is_group: 0,
-      // cli declares 'public' for DMs: the socket is chmod 0600, so
-      // "connected" ≈ "is the owner".
-      unknown_sender_policy: resolveUnknownSenderPolicy(CLI_CHANNEL, false),
+      unknown_sender_policy: 'public',
       created_at: now,
     };
     createMessagingGroup(cliMg);
@@ -158,15 +148,12 @@ async function main(): Promise<void> {
 
   const existing = getMessagingGroupAgentByPair(cliMg.id, ag.id);
   if (!existing) {
-    // cli declares pattern '.' for DMs — every line the operator types is
-    // for the agent. Identical to the pre-declaration hardcodes.
-    const engage = resolveWiringDefaults(CLI_CHANNEL, false, ag.name);
     createMessagingGroupAgent({
       id: generateId('mga'),
       messaging_group_id: cliMg.id,
       agent_group_id: ag.id,
-      engage_mode: engage.engage_mode,
-      engage_pattern: engage.engage_pattern,
+      engage_mode: 'pattern',
+      engage_pattern: '.',
       sender_scope: 'all',
       ignored_message_policy: 'drop',
       session_mode: 'shared',

scripts/init-first-agent.ts

@@ -25,8 +25,7 @@
  *     --display-name "Gavriel" \
  *     [--agent-name "Andy"] \
  *     [--welcome "System instruction: ..."] \
- *     [--role owner|admin|member] \  # default: owner
- *     [--engage-pattern "."]         # explicit DM engage regex override
+ *     [--role owner|admin|member]    # default: owner
  *
  * For direct-addressable channels (telegram, whatsapp, etc.), --platform-id
  * is typically the same as the handle in --user-id, with the channel prefix.
@@ -35,16 +34,6 @@ import fs from 'fs';
 import net from 'net';
 import path from 'path';
 
-// Registration-only barrel import: channel modules call
-// registerChannelAdapter() at module scope (factories are NOT invoked, no
-// adapter connects — no Gateway conflict with the running service), so
-// declared channel defaults resolve here without live adapters.
-import '../src/channels/index.js';
-import {
-  resolveUnknownSenderPolicy,
-  resolveWiringDefaults,
-} from '../src/channels/channel-defaults.js';
-import { hasDeclaredChannelDefaults } from '../src/channels/channel-registry.js';
 import { DATA_DIR, GROUPS_DIR } from '../src/config.js';
 import { createAgentGroup, getAgentGroupByFolder } from '../src/db/agent-groups.js';
 import { initDb } from '../src/db/connection.js';
@@ -73,8 +62,6 @@ interface Args {
   agentName: string;
   welcome: string;
   role: Role;
-  /** Explicit engage regex for the DM wiring; omitted = channel declaration / '.'. */
-  engagePattern?: string;
 }
 
 const DEFAULT_WELCOME =
@@ -112,10 +99,6 @@ function parseArgs(argv: string[]): Args {
         out.welcome = val;
         i++;
         break;
-      case '--engage-pattern':
-        out.engagePattern = val;
-        i++;
-        break;
       case '--role': {
         const raw = (val ?? '').toLowerCase();
         if (raw !== 'owner' && raw !== 'admin' && raw !== 'member') {
@@ -149,7 +132,6 @@ function parseArgs(argv: string[]): Args {
     agentName: out.agentName?.trim() || out.displayName!,
     welcome: out.welcome?.trim() || DEFAULT_WELCOME,
     role: out.role ?? DEFAULT_ROLE,
-    engagePattern: out.engagePattern?.trim() || undefined,
   };
 }
 
@@ -161,41 +143,21 @@ function generateId(prefix: string): string {
   return `${prefix}-${Date.now()}-${Math.random().toString(36).slice(2, 8)}`;
 }
 
-function wireIfMissing(
-  mg: MessagingGroup,
-  ag: AgentGroup,
-  now: string,
-  label: string,
-  engagePattern?: string,
-): void {
+function wireIfMissing(mg: MessagingGroup, ag: AgentGroup, now: string, label: string): void {
   const existing = getMessagingGroupAgentByPair(mg.id, ag.id);
   if (existing) {
     console.log(`Wiring already exists: ${existing.id} (${label})`);
     return;
   }
-  // Engage defaults, first hit wins: explicit --engage-pattern → the
-  // channel's declared defaults → the legacy heuristic for stale
-  // (undeclared) adapters: DMs (is_group=0) respond to everything via a '.'
-  // regex, group chats are mention-only; admins can reconfigure via
-  // /manage-channels once the agent is in use.
-  const isGroup = mg.is_group === 1;
-  const channelKey = mg.instance ?? mg.channel_type;
-  const engage = engagePattern
-    ? { engage_mode: 'pattern' as const, engage_pattern: engagePattern }
-    : hasDeclaredChannelDefaults(channelKey, mg.channel_type)
-      ? resolveWiringDefaults(channelKey, isGroup, ag.name, mg.channel_type)
-      : isGroup
-        ? { engage_mode: 'mention' as const, engage_pattern: null }
-        : { engage_mode: 'pattern' as const, engage_pattern: '.' };
   createMessagingGroupAgent({
     id: generateId('mga'),
     messaging_group_id: mg.id,
     agent_group_id: ag.id,
-    engage_mode: engage.engage_mode,
-    engage_pattern: engage.engage_pattern,
-    // Deliberate owner-bootstrap choices, not channel defaults: the operator
-    // wires their own DM, so every sender is trusted ('all') and ignored
-    // messages carry no value ('drop').
+    // DM / CLI (is_group=0) default to "respond to everything" via a '.' regex.
+    // Group chats default to mention-only; admins can upgrade to mention-sticky
+    // via /manage-channels once the agent is in use.
+    engage_mode: mg.is_group === 0 ? 'pattern' : 'mention',
+    engage_pattern: mg.is_group === 0 ? '.' : null,
     sender_scope: 'all',
     ignored_message_policy: 'drop',
     session_mode: 'shared',
@@ -315,18 +277,13 @@ async function main(): Promise<void> {
   let dmMg = getMessagingGroupByPlatform(args.channel, platformId);
   if (!dmMg) {
     const mgId = generateId('mg');
-    // Policy from the channel declaration (DM context); legacy 'strict' for
-    // stale (undeclared) adapters so a trunk update alone changes nothing.
-    const unknownSenderPolicy = hasDeclaredChannelDefaults(args.channel)
-      ? resolveUnknownSenderPolicy(args.channel, false)
-      : 'strict';
     createMessagingGroup({
       id: mgId,
       channel_type: args.channel,
       platform_id: platformId,
       name: args.displayName,
       is_group: 0,
-      unknown_sender_policy: unknownSenderPolicy,
+      unknown_sender_policy: 'strict',
       created_at: now,
     });
     dmMg = getMessagingGroupByPlatform(args.channel, platformId)!;
@@ -336,7 +293,7 @@ async function main(): Promise<void> {
   }
 
   // 4. Wire DM messaging group to the agent.
-  wireIfMissing(dmMg, ag, now, 'dm', args.engagePattern);
+  wireIfMissing(dmMg, ag, now, 'dm');
 
   // 5. Welcome delivery over the CLI socket. Router picks up the line,
   // writes the message into the DM session's inbound.db, and wakes the

scripts/seed-discord.ts

@@ -60,9 +60,6 @@ try {
     agent_group_id: AGENT_GROUP_ID,
     // Discord group channel → mention-sticky default. Mention once, stay
     // subscribed to the thread. Admins can tune via /manage-channels.
-    // Kept manually in sync with DISCORD_DEFAULTS.group on the channels
-    // branch (the adapter is skill-installed, so the declaration can't be
-    // imported here) — re-check this hardcode if that declaration changes.
     engage_mode: 'mention-sticky',
     engage_pattern: null,
     sender_scope: 'all',

scripts/test-v2-agent.ts

@@ -34,10 +34,9 @@ db.exec(`
 
 // Insert test message
 db.prepare(
-  `INSERT INTO messages_in (id, kind, timestamp, status, content) VALUES (?, 'chat', ?, 'pending', ?)`,
+  `INSERT INTO messages_in (id, kind, timestamp, status, content) VALUES (?, 'chat', datetime('now'), 'pending', ?)`,
 ).run(
   'test-1',
-  new Date().toISOString(),
   JSON.stringify({ sender: 'Gavriel', text: 'Say "Hello from v2!" and nothing else. Do not use any tools.' }),
 );
 console.log('✓ Session DB created with test message');

setup/add-slack.sh

@@ -51,7 +51,6 @@ fi
 
 need_install() {
   [ ! -f src/channels/slack.ts ] && return 0
-  [ ! -f container/skills/slack-formatting/SKILL.md ] && return 0
   ! grep -q "^import './slack.js';" src/channels/index.ts 2>/dev/null && return 0
   return 1
 }
@@ -68,10 +67,6 @@ if need_install; then
   log "Copying adapter from ${CHANNELS_BRANCH}…"
   git show "${CHANNELS_BRANCH}:src/channels/slack.ts" > src/channels/slack.ts
 
-  # Slack formatting container skill — reaches agents via ~/.claude/skills.
-  mkdir -p container/skills/slack-formatting
-  git show "${CHANNELS_BRANCH}:container/skills/slack-formatting/SKILL.md" > container/skills/slack-formatting/SKILL.md
-
   # Append self-registration import if missing.
   if ! grep -q "^import './slack.js';" src/channels/index.ts; then
     echo "import './slack.js';" >> src/channels/index.ts

setup/add-whatsapp.sh

@@ -43,7 +43,6 @@ log() { echo "[add-whatsapp] $*" >&2; }
 need_install() {
   [ ! -f src/channels/whatsapp.ts ] && return 0
   [ ! -f setup/groups.ts ] && return 0
-  [ ! -f container/skills/whatsapp-formatting/instructions.md ] && return 0
   ! grep -q "^import './whatsapp.js';" src/channels/index.ts 2>/dev/null && return 0
   ! grep -q "'whatsapp-auth':" setup/index.ts 2>/dev/null && return 0
   ! grep -q "^  groups:" setup/index.ts 2>/dev/null && return 0
@@ -65,12 +64,6 @@ if need_install; then
   git show "${CHANNELS_BRANCH}:src/channels/whatsapp.ts" > src/channels/whatsapp.ts
   git show "${CHANNELS_BRANCH}:setup/groups.ts"          > setup/groups.ts
 
-  # WhatsApp formatting container skill — feeds the composed CLAUDE.md
-  # (skill-whatsapp-formatting.md fragment) and ~/.claude/skills.
-  mkdir -p container/skills/whatsapp-formatting
-  git show "${CHANNELS_BRANCH}:container/skills/whatsapp-formatting/SKILL.md"        > container/skills/whatsapp-formatting/SKILL.md
-  git show "${CHANNELS_BRANCH}:container/skills/whatsapp-formatting/instructions.md" > container/skills/whatsapp-formatting/instructions.md
-
   # Append self-registration import if missing.
   if ! grep -q "^import './whatsapp.js';" src/channels/index.ts; then
     echo "import './whatsapp.js';" >> src/channels/index.ts

setup/auto.ts

@@ -1236,7 +1236,7 @@ async function askChannelChoice(): Promise<ChannelChoice> {
       options: [
         { value: 'telegram', label: 'Yes, connect Telegram', hint: 'recommended' },
         { value: 'discord', label: 'Yes, connect Discord' },
-        { value: 'whatsapp', label: 'Yes, connect WhatsApp', hint: 'best with a dedicated number' },
+        { value: 'whatsapp', label: 'Yes, connect WhatsApp' },
         {
           value: 'signal',
           label: 'Yes, connect Signal',

setup/channels/whatsapp.test.ts

@@ -1,70 +0,0 @@
-import fs from 'fs';
-import os from 'os';
-import path from 'path';
-
-import { afterEach, beforeEach, describe, expect, it } from 'vitest';
-
-import { selfChatEngagePattern, writeEnvVar } from './whatsapp.js';
-
-describe('selfChatEngagePattern', () => {
-  it('matches messages starting with @<name> and nothing else', () => {
-    const re = new RegExp(selfChatEngagePattern('Nano'));
-    expect(re.test('@Nano what time is it?')).toBe(true);
-    expect(re.test('@Nano')).toBe(true);
-    expect(re.test('hey @Nano')).toBe(false);
-    expect(re.test('grocery list')).toBe(false);
-    // \b guard: name must end at a word boundary, not prefix a longer word.
-    expect(re.test('@Nanobot hello')).toBe(false);
-  });
-
-  it('escapes regex metacharacters in the agent name', () => {
-    const re = new RegExp(selfChatEngagePattern('C-3PO (backup)'));
-    expect(re.test('@C-3PO (backup) status?')).toBe(true);
-    expect(re.test('@C-3PO Xbackup) status?')).toBe(false);
-  });
-
-  it('drops the trailing \\b for names ending in non-word characters', () => {
-    const pattern = selfChatEngagePattern('Nano!');
-    expect(pattern.endsWith('\\b')).toBe(false);
-    expect(new RegExp(pattern).test('@Nano! do the thing')).toBe(true);
-  });
-});
-
-describe('writeEnvVar', () => {
-  let dir: string;
-  let envPath: string;
-
-  beforeEach(() => {
-    dir = fs.mkdtempSync(path.join(os.tmpdir(), 'nanoclaw-env-'));
-    envPath = path.join(dir, '.env');
-  });
-
-  afterEach(() => {
-    fs.rmSync(dir, { recursive: true, force: true });
-  });
-
-  it('creates the file when missing', () => {
-    writeEnvVar('ASSISTANT_NAME', 'Nano', envPath);
-    expect(fs.readFileSync(envPath, 'utf-8')).toBe('ASSISTANT_NAME=Nano\n');
-  });
-
-  it('appends to an existing file, adding a newline if needed', () => {
-    fs.writeFileSync(envPath, 'TZ=UTC');
-    writeEnvVar('ASSISTANT_HAS_OWN_NUMBER', 'true', envPath);
-    expect(fs.readFileSync(envPath, 'utf-8')).toBe(
-      'TZ=UTC\nASSISTANT_HAS_OWN_NUMBER=true\n',
-    );
-  });
-
-  it('replaces an existing line in place without touching neighbors', () => {
-    fs.writeFileSync(envPath, 'ASSISTANT_NAME=Andy\nTZ=UTC\n');
-    writeEnvVar('ASSISTANT_NAME', 'Nano', envPath);
-    expect(fs.readFileSync(envPath, 'utf-8')).toBe('ASSISTANT_NAME=Nano\nTZ=UTC\n');
-  });
-
-  it('keeps $-sequences in the value literal', () => {
-    fs.writeFileSync(envPath, 'ASSISTANT_NAME=Andy\n');
-    writeEnvVar('ASSISTANT_NAME', "$& $' $1", envPath);
-    expect(fs.readFileSync(envPath, 'utf-8')).toBe("ASSISTANT_NAME=$& $' $1\n");
-  });
-});

setup/channels/whatsapp.ts

@@ -1,32 +1,24 @@
 /**
  * WhatsApp (community/Baileys) channel flow for setup:auto.
  *
- * `runWhatsAppChannel(displayName)` owns the full branch from number-
- * ownership picker through the welcome DM:
+ * `runWhatsAppChannel(displayName)` owns the full branch from auth-method
+ * picker through the welcome DM:
  *
- *   1. Ask whether the agent gets a dedicated number or shares the
- *      operator's personal one. Personal ⇒ interception screen that spells
- *      out self-chat-only mode and steers toward alternatives (default is
- *      back to channel selection)
- *   2. Ask how to authenticate (QR code in terminal, default, or pairing code)
- *   3. If pairing-code: collect the phone number
- *   4. Install the adapter + Baileys + QR + pino via setup/add-whatsapp.sh
- *   5. Run the whatsapp-auth step, rendering status blocks as clack UI:
+ *   1. Ask how to authenticate (QR code in terminal, default, or pairing code)
+ *   2. If pairing-code: collect the phone number
+ *   3. Install the adapter + Baileys + QR + pino via setup/add-whatsapp.sh
+ *   4. Run the whatsapp-auth step, rendering status blocks as clack UI:
  *      - WHATSAPP_AUTH_QR (repeating): render the QR as terminal block art
  *        inside a clack note. On rotation we clear the previous QR in-place
  *        via ANSI escapes so the terminal doesn't fill up with stale codes.
  *      - WHATSAPP_AUTH_PAIRING_CODE (one-shot): centred code card.
- *   6. Read store/auth/creds.json → extract the authenticated (bot) phone
- *   7. Dedicated: ask for the operator's personal number (the one they'll
- *      chat from) and write ASSISTANT_HAS_OWN_NUMBER=true so outbound
- *      replies aren't prefixed. Entering the bot's own number routes back
- *      through the interception screen. Shared: chat number = bot number
- *   8. Ask for the messaging-agent name (defaulting to "Nano"); persist it
- *      as ASSISTANT_NAME so the adapter's outbound prefix matches. Shared
- *      mode also offers an @<name>-only engage pattern for the self-chat
- *   9. Kick the service — AFTER the env writes, since the adapter reads
- *      ASSISTANT_HAS_OWN_NUMBER / ASSISTANT_NAME once at module load
- *  10. Wire the agent via scripts/init-first-agent.ts; the existing welcome
+ *   5. Read store/auth/creds.json → extract the authenticated (bot) phone
+ *   6. Kick the service so the adapter picks up the new credentials
+ *   7. Ask the operator for the phone they'll chat from (defaults to the
+ *      authed number). Different number ⇒ dedicated mode ⇒ also writes
+ *      ASSISTANT_HAS_OWN_NUMBER=true so outbound replies aren't prefixed
+ *   8. Ask for the messaging-agent name (defaulting to "Nano")
+ *   9. Wire the agent via scripts/init-first-agent.ts; the existing welcome
  *      DM path delivers the greeting through the adapter
  *
  * All output obeys the three-level contract: clack UI for the user, structured
@@ -63,14 +55,6 @@ const AUTH_CREDS_PATH = path.join(process.cwd(), 'store', 'auth', 'creds.json');
 type AuthMethod = 'qr' | 'pairing-code';
 
 export async function runWhatsAppChannel(displayName: string): Promise<ChannelFlowResult> {
-  const ownership = await askNumberOwnership();
-  if (ownership === 'back') return BACK_TO_CHANNEL_SELECTION;
-  let mode: 'dedicated' | 'shared' = ownership;
-  if (mode === 'shared') {
-    const proceed = await confirmSharedNumber();
-    if (proceed === 'back') return BACK_TO_CHANNEL_SELECTION;
-  }
-
   const method = await askAuthMethod();
   if (method === 'back') return BACK_TO_CHANNEL_SELECTION;
   const phone = method === 'pairing-code' ? await askPhoneNumber() : undefined;
@@ -114,35 +98,18 @@ export async function runWhatsAppChannel(displayName: string): Promise<ChannelFl
     );
   }
 
-  let chatPhone = botPhone;
-  if (mode === 'dedicated') {
-    chatPhone = await askChatPhone(botPhone);
-    if (chatPhone === botPhone) {
-      // Chatting from the bot's own number IS the shared-number setup —
-      // route through the same interception screen as the up-front pick.
-      const proceed = await confirmSharedNumber();
-      if (proceed === 'back') return BACK_TO_CHANNEL_SELECTION;
-      mode = 'shared';
-    }
+  await restartService();
+
+  const chatPhone = await askChatPhone(botPhone);
+  const isDedicated = chatPhone !== botPhone;
+  if (isDedicated) {
+    writeAssistantHasOwnNumber();
   }
-  // Written in both modes so a re-run that switches dedicated → shared
-  // doesn't leave a stale `true` behind.
-  writeEnvVar('ASSISTANT_HAS_OWN_NUMBER', mode === 'dedicated' ? 'true' : 'false');
 
   const role = await askOperatorRole('WhatsApp');
   setupLog.userInput('whatsapp_role', role);
 
   const agentName = await resolveAgentName();
-  // Both modes: keep the adapter's outbound prefix / mention normalization
-  // in sync with the chosen agent name (config default is 'Andy' otherwise).
-  writeEnvVar('ASSISTANT_NAME', agentName);
-
-  const engagePattern = mode === 'shared' ? await askSelfChatEngage(agentName) : undefined;
-
-  // Restart only after ASSISTANT_HAS_OWN_NUMBER / ASSISTANT_NAME land in
-  // .env — the adapter computes its shared/dedicated mode and name once at
-  // module load, so restarting earlier would leave it running with defaults.
-  await restartService();
 
   const platformId = `${chatPhone}@s.whatsapp.net`;
 
@@ -157,11 +124,10 @@ export async function runWhatsAppChannel(displayName: string): Promise<ChannelFl
       '--display-name', displayName,
       '--agent-name', agentName,
       '--role', role,
-      ...(engagePattern ? ['--engage-pattern', engagePattern] : []),
     ],
     {
       running: `Connecting ${agentName} to WhatsApp…`,
-      done: mode === 'dedicated'
+      done: isDedicated
         ? `${agentName} is ready. Check WhatsApp for a welcome message.`
         : `${agentName} is ready. Look in your "You" chat on WhatsApp for the welcome.`,
     },
@@ -170,7 +136,7 @@ export async function runWhatsAppChannel(displayName: string): Promise<ChannelFl
         CHANNEL: 'whatsapp',
         AGENT_NAME: agentName,
         PLATFORM_ID: platformId,
-        MODE: mode,
+        MODE: isDedicated ? 'dedicated' : 'shared',
         ROLE: role,
       },
     },
@@ -182,112 +148,6 @@ export async function runWhatsAppChannel(displayName: string): Promise<ChannelFl
       'You can retry later with `/manage-channels`.',
     );
   }
-  if (mode === 'shared') {
-    note(
-      [
-        'Only your self-chat is connected. Messages other people send to your',
-        'number are ignored — never seen, never asked about.',
-        '',
-        k.dim('Wire a specific chat later with /manage-channels.'),
-      ].join('\n'),
-      'Self-chat mode',
-    );
-  }
-}
-
-async function askNumberOwnership(): Promise<'dedicated' | 'shared' | 'back'> {
-  const choice = ensureAnswer(
-    await brightSelect({
-      message: 'Which WhatsApp number will your agent use?',
-      options: [
-        {
-          value: 'dedicated',
-          label: 'A dedicated number just for the agent',
-          hint: 'recommended — spare SIM, eSIM, or old phone',
-        },
-        {
-          value: 'shared',
-          label: 'My own personal number',
-        },
-        {
-          value: 'back',
-          label: '← Back to channel selection',
-        },
-      ],
-    }),
-  ) as 'dedicated' | 'shared' | 'back';
-  if (choice !== 'back') setupLog.userInput('whatsapp_number_ownership', choice);
-  return choice;
-}
-
-/**
- * Interception screen for the shared-number path: make the self-chat-only
- * tradeoff explicit and steer toward alternatives before any install or
- * auth happens. Default is bailing back to channel selection.
- */
-async function confirmSharedNumber(): Promise<'continue' | 'back'> {
-  note(
-    [
-      'On your personal number, the agent lives only in your "You" / self-chat.',
-      'Messages other people send you are ignored entirely — never read, never',
-      'answered, never flagged for approval. Nobody else can talk to the agent.',
-      '',
-      'If you want the agent reachable as its own contact, consider:',
-      '',
-      `  • ${brandBold('Telegram')} — a bot takes ~2 minutes to set up`,
-      `  • ${brandBold('a dedicated WhatsApp number')} — spare SIM, eSIM, or old phone`,
-      `  • ${brandBold('/add-whatsapp-cloud')} — the official Meta Business API`,
-    ].join('\n'),
-    'Personal number = self-chat only',
-  );
-  const choice = ensureAnswer(
-    await brightSelect({
-      message: 'How would you like to proceed?',
-      options: [
-        { value: 'back', label: '← Pick a different channel' },
-        { value: 'continue', label: 'Continue — self-chat only' },
-      ],
-      initialValue: 'back',
-    }),
-  ) as 'continue' | 'back';
-  setupLog.userInput('whatsapp_shared_confirm', choice);
-  return choice;
-}
-
-/**
- * Shared mode only: choose whether the agent answers everything in the
- * self-chat or only messages addressed to it by name. Returns the engage
- * regex for init-first-agent's --engage-pattern, or undefined for the
- * respond-to-everything default.
- */
-async function askSelfChatEngage(agentName: string): Promise<string | undefined> {
-  const choice = ensureAnswer(
-    await brightSelect({
-      message: `Respond to every self-chat message, or only messages starting with @${agentName}?`,
-      options: [
-        {
-          value: 'all',
-          label: 'Every message',
-          hint: "the self-chat becomes the agent's inbox",
-        },
-        {
-          value: 'mention',
-          label: `Only messages starting with @${agentName}`,
-          hint: 'keep the self-chat for your own notes too',
-        },
-      ],
-    }),
-  ) as 'all' | 'mention';
-  setupLog.userInput('whatsapp_selfchat_engage', choice);
-  return choice === 'all' ? undefined : selfChatEngagePattern(agentName);
-}
-
-/** Engage regex for "only messages starting with @<name>". Exported for tests. */
-export function selfChatEngagePattern(agentName: string): string {
-  const escaped = agentName.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
-  // \b only terminates a match after a word character — skip it for names
-  // ending in punctuation, where it would never match.
-  return /\w$/.test(agentName) ? `^@${escaped}\\b` : `^@${escaped}`;
 }
 
 async function askAuthMethod(): Promise<AuthMethod | 'back'> {
@@ -499,7 +359,7 @@ function readAuthedPhone(): string {
 
 async function restartService(): Promise<void> {
   const s = p.spinner();
-  s.start('Restarting NanoClaw so it sees your WhatsApp credentials and settings…');
+  s.start('Restarting NanoClaw so it sees your WhatsApp credentials…');
   const start = Date.now();
   const platform = process.platform;
   try {
@@ -542,20 +402,25 @@ async function restartService(): Promise<void> {
 async function askChatPhone(authedPhone: string): Promise<string> {
   note(
     [
-      `The agent is signed in as ${k.cyan('+' + authedPhone)}.`,
+      `Authenticated with ${k.cyan('+' + authedPhone)}.`,
       '',
-      "Now, your personal number — the one you'll chat with the agent from.",
-      "It'll show up as a normal two-way conversation with the agent's contact.",
+      "What's the phone number you'll chat with your agent from?",
+      '',
+      k.dim(
+        'Same number = messages will land in your "You" / self-chat on WhatsApp\n' +
+          "(you won't be able to reply to yourself — use a different number for a\n" +
+          'two-way chat).',
+      ),
     ].join('\n'),
-    'Your personal number',
+    'Your chat number',
   );
   const answer = ensureAnswer(
     await p.text({
-      message: "Your personal number, where you'll chat from",
-      placeholder: 'e.g. 14155551234',
+      message: 'Your personal phone number',
+      placeholder: authedPhone,
+      defaultValue: authedPhone,
       validate: (v) => {
-        const t = (v ?? '').trim();
-        if (!t) return 'Phone number is required';
+        const t = (v ?? authedPhone).trim();
         if (!/^\d{8,15}$/.test(t)) {
           return 'Digits only, country code included.';
         }
@@ -563,31 +428,28 @@ async function askChatPhone(authedPhone: string): Promise<string> {
       },
     }),
   );
-  const phone = (answer as string).trim();
+  const phone = ((answer as string) || authedPhone).trim();
   setupLog.userInput('whatsapp_chat_phone', phone);
   return phone;
 }
 
-/** Persist KEY=value to .env, replacing any existing KEY line. Exported for tests. */
-export function writeEnvVar(
-  key: string,
-  value: string,
-  envPath: string = path.join(process.cwd(), '.env'),
-): void {
+/** Persist ASSISTANT_HAS_OWN_NUMBER=true to .env. */
+function writeAssistantHasOwnNumber(): void {
+  const envPath = path.join(process.cwd(), '.env');
   let contents = '';
   try {
     contents = fs.readFileSync(envPath, 'utf-8');
   } catch {
     contents = '';
   }
-  const line = `${key}=${value}`;
-  const existing = new RegExp(`^${key}=.*$`, 'm');
-  if (existing.test(contents)) {
-    // Replacement via callback so `$`-sequences in the value stay literal.
-    contents = contents.replace(existing, () => line);
+  if (/^ASSISTANT_HAS_OWN_NUMBER=/m.test(contents)) {
+    contents = contents.replace(
+      /^ASSISTANT_HAS_OWN_NUMBER=.*$/m,
+      'ASSISTANT_HAS_OWN_NUMBER=true',
+    );
   } else {
     if (contents.length > 0 && !contents.endsWith('\n')) contents += '\n';
-    contents += line + '\n';
+    contents += 'ASSISTANT_HAS_OWN_NUMBER=true\n';
   }
   fs.writeFileSync(envPath, contents);
 }

setup/install-slack.sh

@@ -15,7 +15,6 @@ echo "=== NANOCLAW SETUP: INSTALL_SLACK ==="
 
 needs_install=false
 [[ -f src/channels/slack.ts ]] || needs_install=true
-[[ -f container/skills/slack-formatting/SKILL.md ]] || needs_install=true
 grep -q "import './slack.js';" src/channels/index.ts || needs_install=true
 grep -q '"@chat-adapter/slack"' package.json || needs_install=true
 [[ -d node_modules/@chat-adapter/slack ]] || needs_install=true
@@ -31,8 +30,6 @@ git fetch origin channels
 
 echo "STEP: copy-files"
 git show origin/channels:src/channels/slack.ts > src/channels/slack.ts
-mkdir -p container/skills/slack-formatting
-git show origin/channels:container/skills/slack-formatting/SKILL.md > container/skills/slack-formatting/SKILL.md
 
 echo "STEP: register-import"
 if ! grep -q "import './slack.js';" src/channels/index.ts; then

setup/install-whatsapp.sh

@@ -20,8 +20,6 @@ CHANNEL_FILES=(
   src/channels/whatsapp.ts
   setup/whatsapp-auth.ts
   setup/groups.ts
-  container/skills/whatsapp-formatting/SKILL.md
-  container/skills/whatsapp-formatting/instructions.md
 )
 
 needs_install=false
@@ -47,7 +45,6 @@ git fetch origin channels
 
 echo "STEP: copy-files"
 for f in "${CHANNEL_FILES[@]}"; do
-  mkdir -p "$(dirname "$f")"
   git show "origin/channels:$f" > "$f"
 done
 

setup/register.ts

@@ -7,16 +7,6 @@
 import fs from 'fs';
 import path from 'path';
 
-// Registration-only barrel import: each channel module calls
-// registerChannelAdapter() at module scope (factories are NOT invoked, no
-// adapter connects), so declared channel defaults resolve without the service.
-import '../src/channels/index.js';
-import {
-  resolveUnknownSenderPolicy,
-  resolveWiringDefaults,
-  validateEngageAgainstChannel,
-} from '../src/channels/channel-defaults.js';
-import { hasDeclaredChannelDefaults } from '../src/channels/channel-registry.js';
 import { DATA_DIR } from '../src/config.js';
 import { initDb } from '../src/db/connection.js';
 import { runMigrations } from '../src/db/migrations/index.js';
@@ -43,7 +33,7 @@ interface RegisterArgs {
   trigger: string;
   /** Agent group folder name */
   folder: string;
-  /** Channel type (discord, slack, telegram, etc.) — required */
+  /** Channel type (discord, slack, telegram, etc.) */
   channel: string;
   /** Whether messages require the trigger pattern to activate */
   requiresTrigger: boolean;
@@ -51,28 +41,18 @@ interface RegisterArgs {
   assistantName: string;
   /** Session mode: 'shared' (one session per channel) or 'per-thread' */
   sessionMode: string;
-  /** Whether the messaging group is a multi-user chat (default: true) */
-  isGroup: boolean;
-  /** Explicit engage mode override; omitted = channel declaration / heuristic */
-  engageMode?: 'pattern' | 'mention' | 'mention-sticky';
-  /** Explicit unknown_sender_policy override; omitted = channel declaration / 'strict' */
-  unknownSenderPolicy?: 'strict' | 'request_approval' | 'public';
 }
 
-const ENGAGE_MODES = ['pattern', 'mention', 'mention-sticky'] as const;
-const SENDER_POLICIES = ['strict', 'request_approval', 'public'] as const;
-
 function parseArgs(args: string[]): RegisterArgs {
   const result: RegisterArgs = {
     platformId: '',
     name: '',
     trigger: '',
     folder: '',
-    channel: '',
+    channel: 'discord',
     requiresTrigger: false,
     assistantName: 'Andy',
     sessionMode: 'shared',
-    isGroup: true,
   };
 
   for (let i = 0; i < args.length; i++) {
@@ -101,32 +81,6 @@ function parseArgs(args: string[]): RegisterArgs {
       case '--session-mode':
         result.sessionMode = args[++i] || 'shared';
         break;
-      case '--is-group': {
-        const raw = (args[++i] || '').toLowerCase();
-        if (!['true', 'false', '1', '0'].includes(raw)) {
-          throw new Error(`--is-group must be true or false, got "${raw}"`);
-        }
-        result.isGroup = raw === 'true' || raw === '1';
-        break;
-      }
-      case '--engage-mode': {
-        const raw = (args[++i] || '').toLowerCase() as RegisterArgs['engageMode'];
-        if (!raw || !ENGAGE_MODES.includes(raw)) {
-          throw new Error(`--engage-mode must be one of ${ENGAGE_MODES.join('|')}, got "${raw}"`);
-        }
-        result.engageMode = raw;
-        break;
-      }
-      case '--unknown-sender-policy': {
-        const raw = (args[++i] || '').toLowerCase() as RegisterArgs['unknownSenderPolicy'];
-        if (!raw || !SENDER_POLICIES.includes(raw)) {
-          throw new Error(
-            `--unknown-sender-policy must be one of ${SENDER_POLICIES.join('|')}, got "${raw}"`,
-          );
-        }
-        result.unknownSenderPolicy = raw;
-        break;
-      }
     }
   }
 
@@ -141,19 +95,6 @@ export async function run(args: string[]): Promise<void> {
   const projectRoot = process.cwd();
   const parsed = parseArgs(args);
 
-  if (!parsed.channel) {
-    // No silent platform default: the channel decides platform-id namespacing
-    // and the wiring/policy defaults below, so guessing one wires the chat to
-    // the wrong adapter.
-    emitStatus('REGISTER_CHANNEL', {
-      STATUS: 'failed',
-      ERROR: 'missing_channel',
-      MESSAGE: '--channel is required (the channel type this chat lives on, e.g. discord, slack, telegram, whatsapp)',
-      LOG: 'logs/setup.log',
-    });
-    process.exit(4);
-  }
-
   if (!parsed.platformId || !parsed.name || !parsed.folder) {
     emitStatus('REGISTER_CHANNEL', {
       STATUS: 'failed',
@@ -209,20 +150,13 @@ export async function run(args: string[]): Promise<void> {
   let messagingGroup = getMessagingGroupByPlatform(parsed.channel, parsed.platformId);
   if (!messagingGroup) {
     const mgId = generateId('mg');
-    // Policy: explicit flag → channel declaration → legacy 'strict' (stale
-    // adapters without a declaration must keep pre-declaration behavior).
-    const unknownSenderPolicy =
-      parsed.unknownSenderPolicy ??
-      (hasDeclaredChannelDefaults(parsed.channel)
-        ? resolveUnknownSenderPolicy(parsed.channel, parsed.isGroup)
-        : 'strict');
     createMessagingGroup({
       id: mgId,
       channel_type: parsed.channel,
       platform_id: parsed.platformId,
       name: parsed.name,
-      is_group: parsed.isGroup ? 1 : 0,
-      unknown_sender_policy: unknownSenderPolicy,
+      is_group: 1,
+      unknown_sender_policy: 'strict',
       created_at: new Date().toISOString(),
     });
     messagingGroup = getMessagingGroupByPlatform(parsed.channel, parsed.platformId)!;
@@ -236,41 +170,19 @@ export async function run(args: string[]): Promise<void> {
   if (!existing) {
     newlyWired = true;
     const mgaId = generateId('mga');
-    // Engage defaults, first hit wins: explicit --engage-mode → explicit
-    // --trigger (pattern regex, the historical override) → the channel's
-    // declared defaults → the legacy heuristic for stale (undeclared)
-    // adapters, so a trunk update alone changes nothing for them: groups get
-    // 'mention' (respond when addressed), DMs 'pattern'/'.' (every message).
+    // Mirrors scripts/init-first-agent.ts:wireIfMissing so both setup paths
+    // create rows with the same shape. Groups default to 'mention' (bot only
+    // responds when addressed); DMs default to 'pattern'/'.' (respond to
+    // every message). An explicit --trigger overrides the pattern regex.
     const isGroup = messagingGroup.is_group === 1;
-    const channelKey = messagingGroup.instance ?? messagingGroup.channel_type;
-    let engage: { engage_mode: 'pattern' | 'mention' | 'mention-sticky'; engage_pattern: string | null };
-    if (parsed.engageMode) {
-      if (parsed.engageMode === 'pattern' && !parsed.trigger) {
-        throw new Error(`--engage-mode pattern requires --trigger (use "." to match every message)`);
-      }
-      engage = {
-        engage_mode: parsed.engageMode,
-        engage_pattern: parsed.engageMode === 'pattern' ? parsed.trigger : null,
-      };
-    } else if (parsed.trigger) {
-      engage = { engage_mode: 'pattern', engage_pattern: parsed.trigger };
-    } else if (hasDeclaredChannelDefaults(channelKey, messagingGroup.channel_type)) {
-      engage = resolveWiringDefaults(channelKey, isGroup, agentGroup.name, messagingGroup.channel_type);
-    } else {
-      engage = isGroup
-        ? { engage_mode: 'mention', engage_pattern: null }
-        : { engage_mode: 'pattern', engage_pattern: '.' };
-    }
-    // Same cross-checks as `ncl wirings create`: rejects mention modes on
-    // channels declaring mentions:'never'; coerces mention-sticky→mention
-    // when the channel context has no thread ids.
-    validateEngageAgainstChannel(engage, messagingGroup);
+    const engageMode: 'pattern' | 'mention' = isGroup && !parsed.trigger ? 'mention' : 'pattern';
+    const engagePattern: string | null = engageMode === 'pattern' ? parsed.trigger || '.' : null;
     createMessagingGroupAgent({
       id: mgaId,
       messaging_group_id: messagingGroup.id,
       agent_group_id: agentGroup.id,
-      engage_mode: engage.engage_mode,
-      engage_pattern: engage.engage_pattern,
+      engage_mode: engageMode,
+      engage_pattern: engagePattern,
       sender_scope: 'all',
       ignored_message_policy: 'drop',
       session_mode: parsed.sessionMode as 'shared' | 'per-thread' | 'agent-shared',

setup/uninstall/remove.ts

@@ -46,12 +46,10 @@ export function backupEnv(envPath: string): string {
   const dir = path.dirname(envPath);
   let backup = path.join(dir, '.env.bak');
   if (fs.existsSync(backup)) {
-    // Local time (system TZ) — the stamp is read by the human running the
-    // uninstall. sv-SE renders "YYYY-MM-DD HH:mm:ss".
     const stamp = new Date()
-      .toLocaleString('sv-SE', { hour12: false })
+      .toISOString()
       .replace(/[-:]/g, '')
-      .replace(' ', '-')
+      .replace('T', '-')
       .slice(0, 15);
     backup = path.join(dir, `.env.bak.${stamp}`);
   }

src/audit/emit.ts

@@ -1,16 +1,14 @@
 /**
- * The single emit seam. Adapters import emitAuditEvent from here directly
- * (it is deliberately not re-exported by the barrel): only src/audit/ and
- * `*.audit.ts` adapter files may call it — grep holds the invariant.
+ * emitAuditEvent — the single opt-in check and the single append point.
  *
- * The opt-in check lives here, so the whole feature switches at one point.
- * Fail-open + loud: a failed append (or a throwing input thunk) is
- * log.error'd and the audited action proceeds.
+ * Only src/audit/ may call this (wrappers compose it at module edges;
+ * business logic never does): `grep emitAuditEvent src/` outside this
+ * directory must stay empty.
  */
 import { randomUUID } from 'crypto';
 
+import { AUDIT_ENABLED } from '../config.js';
 import { log } from '../log.js';
-import { AUDIT_ENABLED } from './config.js';
 import { notifyAuditHooks } from './hooks.js';
 import { redactDetails } from './redact.js';
 import { appendAuditLine } from './store.js';
@@ -19,11 +17,14 @@ import type { AuditEvent, AuditEventInput } from './types.js';
 export function emitAuditEvent(input: AuditEventInput | (() => AuditEventInput)): void {
   if (!AUDIT_ENABLED) return; // The one opt-in check — the whole feature switches here.
   try {
+    // Lazy inputs keep a disabled box at literally zero audit work (and shield
+    // the action from assembly errors — origin lookups can touch the DB).
     if (typeof input === 'function') input = input();
     const event: AuditEvent = {
       event_id: randomUUID(),
       time: new Date().toISOString(),
       schema_version: 1,
+      // Directory-enrichment fields stamp null until the adapter lands.
       actor: { ...input.actor, email: null, user_id: null, group_ids: null },
       origin: input.origin,
       action: input.action,
@@ -34,9 +35,14 @@ export function emitAuditEvent(input: AuditEventInput | (() => AuditEventInput))
     };
     const line = JSON.stringify(event);
     appendAuditLine(line);
+    // Post-write hooks: fired only after the append succeeded, so an exporter
+    // can never know an event the source of truth doesn't. Failures are
+    // isolated inside notifyAuditHooks.
     notifyAuditHooks(event, line);
-    // eslint-disable-next-line no-catch-all/no-catch-all -- fail-open is the posture: an audit failure must never take down the audited action
+    // eslint-disable-next-line no-catch-all/no-catch-all -- fail-open is the contract: auditing must never take down the audited action
   } catch (err) {
+    // Fail-open + loud: the audited action must proceed even when the log
+    // can't be written (a full disk must not brick recovery commands).
     const action = typeof input === 'function' ? undefined : input.action;
     log.error('Audit append failed — action proceeding (fail-open)', { action, err });
   }

src/audit/hooks.test.ts

@@ -11,17 +11,14 @@ vi.mock('../config.js', async (importOriginal) => {
   const actual = await importOriginal<typeof import('../config.js')>();
   return {
     ...actual,
+    get AUDIT_ENABLED() {
+      return state.enabled;
+    },
+    AUDIT_RETENTION_DAYS: 90,
     DATA_DIR: '/tmp/nanoclaw-test-hooks-unused',
   };
 });
 
-vi.mock('./config.js', () => ({
-  get AUDIT_ENABLED() {
-    return state.enabled;
-  },
-  AUDIT_RETENTION_DAYS: 90,
-}));
-
 vi.mock('./store.js', async (importOriginal) => {
   const actual = await importOriginal<typeof import('./store.js')>();
   return {

src/audit/hooks.ts

@@ -29,7 +29,7 @@ export interface AuditHook {
   onEvent(event: AuditEvent, line: string): void;
   /** Boot hook, called only when audit is enabled. Throw = host refuses to start. */
   init?(): void;
-  /** Periodic maintenance — called from the audit maintenance timer (enabled boxes only). */
+  /** Periodic maintenance — called from the 60s host-sweep (enabled boxes only). */
   maintain?(): void;
   /** Graceful-shutdown hook (flush buffers, close handles). */
   shutdown?(): void | Promise<void>;
@@ -67,12 +67,12 @@ export function initAuditHooks(): void {
   }
 }
 
-/** Periodic lifecycle — maintenance, isolated per hook. */
+/** Sweep lifecycle — periodic maintenance, isolated per hook. */
 export function maintainAuditHooks(): void {
   for (const hook of hooks) {
     try {
       hook.maintain?.();
-      // eslint-disable-next-line no-catch-all/no-catch-all -- one hook's maintenance failure must not stop the others (or the timer)
+      // eslint-disable-next-line no-catch-all/no-catch-all -- one hook's maintenance failure must not stop the others (or the sweep)
     } catch (err) {
       log.error('Audit hook maintenance failed', { hook: hook.name, err });
     }

src/audit/index.ts

@@ -0,0 +1,13 @@
+/**
+ * Opt-in local audit log (docs/SECURITY.md, "Local Audit Log").
+ *
+ * Everything composes through the wrappers exported here — business logic
+ * contains zero audit calls. emitAuditEvent is deliberately NOT re-exported:
+ * only src/audit/ internals may call it.
+ */
+export * from './types.js';
+export { redactDetails } from './redact.js';
+export { AUDIT_DIR } from './store.js';
+export { initAuditLog, maintainAudit } from './init.js';
+export { type AuditHook, registerAuditHook } from './hooks.js';
+export { runApprovedHandler, withAudit } from './wrappers.js';

src/audit/init.ts

@@ -0,0 +1,42 @@
+/**
+ * Boot-time audit wiring — one composition line in src/index.ts.
+ *
+ * The decision observer registers unconditionally (its emits no-op when
+ * disabled). When enabled: assert data/audit/ is writable (refusing to start
+ * beats running with a silent audit gap), run the boot prune, and start the
+ * registered post-write hooks' lifecycle (init here, maintain via the host
+ * sweep, shutdown via the host's graceful-shutdown registry).
+ */
+import { AUDIT_ENABLED, AUDIT_RETENTION_DAYS } from '../config.js';
+import { log } from '../log.js';
+import { onShutdown } from '../response-registry.js';
+import { initAuditHooks, maintainAuditHooks, shutdownAuditHooks } from './hooks.js';
+import { registerAuditObserver } from './observer.js';
+import { assertAuditWritable, AUDIT_DIR, markPrunedToday, pruneAuditLog, pruneAuditLogIfDue } from './store.js';
+
+export function initAuditLog(): void {
+  registerAuditObserver();
+  if (!AUDIT_ENABLED) return;
+  try {
+    assertAuditWritable();
+  } catch (err) {
+    throw new Error(
+      `AUDIT_ENABLED=true but the audit directory is not writable: ${AUDIT_DIR} (${err instanceof Error ? err.message : String(err)})`,
+      { cause: err },
+    );
+  }
+  pruneAuditLog();
+  markPrunedToday();
+  initAuditHooks(); // throw → main() exit 1, same posture as the writability assert
+  onShutdown(() => shutdownAuditHooks());
+  log.info('Audit log enabled', { dir: AUDIT_DIR, retentionDays: AUDIT_RETENTION_DAYS });
+}
+
+/**
+ * Host-sweep tick: retention prune (throttled to once per UTC day internally)
+ * plus every hook's periodic maintenance. No-op when audit is disabled.
+ */
+export function maintainAudit(): void {
+  pruneAuditLogIfDue();
+  if (AUDIT_ENABLED) maintainAuditHooks();
+}

src/audit/mapping.ts

@@ -0,0 +1,285 @@
+/**
+ * Event assembly — actors, origins, action names, resources, and the
+ * per-surface details rules (including shape-only for message-bearing
+ * payloads). Pure derivation; nothing here writes the log.
+ */
+import os from 'os';
+
+import { getResource } from '../cli/crud.js';
+import type { CallerContext, RequestFrame } from '../cli/frame.js';
+import { type CommandDef, lookup } from '../cli/registry.js';
+import { getMessagingGroup } from '../db/messaging-groups.js';
+import type { Session } from '../types.js';
+import { type AuditActor, type AuditEventInput, type AuditOrigin, type AuditResource, SYSTEM_ACTOR } from './types.js';
+
+// ── Actors ──
+
+function hostUser(): string {
+  try {
+    return os.userInfo().username;
+    // eslint-disable-next-line no-catch-all/no-catch-all -- os.userInfo throws on exotic hosts; a fallback actor id beats no audit event
+  } catch {
+    return process.env.USER || 'unknown';
+  }
+}
+
+/**
+ * Host callers stamp `host:<install user>` daemon-side: the ncl socket is
+ * 0600 and owned by the install user, so the identity is accurate by
+ * construction without peer credentials.
+ */
+export function actorForCaller(ctx: CallerContext): AuditActor {
+  return ctx.caller === 'host' ? { type: 'human', id: `host:${hostUser()}` } : { type: 'agent', id: ctx.agentGroupId };
+}
+
+/** Empty resolver id (sweep/timer paths) → the system actor. */
+export function humanOrSystemActor(namespacedUserId: string): AuditActor {
+  return namespacedUserId ? { type: 'human', id: namespacedUserId } : SYSTEM_ACTOR;
+}
+
+// ── Origins ──
+
+export function originForCaller(ctx: CallerContext): AuditOrigin {
+  if (ctx.caller === 'host') return { transport: 'socket' };
+  return containerOrigin(ctx.sessionId, ctx.messagingGroupId || null);
+}
+
+export function originForSession(session: Session): AuditOrigin {
+  return containerOrigin(session.id, session.messaging_group_id);
+}
+
+function containerOrigin(sessionId: string, messagingGroupId: string | null): AuditOrigin {
+  const origin: AuditOrigin = { transport: 'container', session_id: sessionId };
+  if (messagingGroupId) {
+    origin.messaging_group_id = messagingGroupId;
+    const channel = getMessagingGroup(messagingGroupId)?.channel_type;
+    if (channel) origin.channel = channel;
+  }
+  return origin;
+}
+
+/** Approval decisions arrive as card clicks on a chat platform. */
+export function channelOriginForUser(namespacedUserId: string): AuditOrigin {
+  const idx = namespacedUserId.indexOf(':');
+  const channel = idx > 0 ? namespacedUserId.slice(0, idx) : undefined;
+  return channel ? { transport: 'channel', channel } : { transport: 'channel' };
+}
+
+// ── CLI resources ──
+
+/**
+ * Frame-level args use `--hyphen-keys`; recorded details use the same
+ * underscore form the parsed handlers see. Mirrors crud's normalizeArgs
+ * (kept local so audit doesn't depend on a module tests commonly mock).
+ */
+export function normalizeArgKeys(raw: Record<string, unknown>): Record<string, unknown> {
+  const out: Record<string, unknown> = {};
+  for (const [k, v] of Object.entries(raw)) {
+    out[k.replace(/-/g, '_')] = v;
+  }
+  return out;
+}
+
+/** CLI resource plural → audit resource type, where the singular isn't it. */
+const RESOURCE_TYPE_OVERRIDES: Record<string, string> = {
+  groups: 'agent_group',
+  'messaging-groups': 'messaging_group',
+  'dropped-messages': 'dropped_message',
+  'user-dms': 'user_dm',
+};
+
+/**
+ * Derive touched/attempted resources from a command's effective args. Generic
+ * by design: `id` → the command's own resource, group/user args → their
+ * types, and a bare `{type}` entry when nothing else is known (a denied
+ * `users list` still names what was attempted).
+ */
+export function resourcesForCli(cmd: CommandDef, args: Record<string, unknown>): AuditResource[] {
+  if (!cmd.resource) return [];
+  const type = RESOURCE_TYPE_OVERRIDES[cmd.resource] ?? getResource(cmd.resource)?.name ?? cmd.resource;
+
+  const out: AuditResource[] = [];
+  const push = (t: string, id: unknown): void => {
+    if (typeof id !== 'string' || !id) return;
+    if (!out.some((r) => r.type === t && r.id === id)) out.push({ type: t, id });
+  };
+  push(type, args.id);
+  push('agent_group', args.agent_group_id ?? args.group);
+  push('user', args.user);
+  if (out.length === 0) out.push({ type });
+  return out;
+}
+
+// ── Approval-gated actions ──
+
+/** Dotted audit action per approval type; cli_command derives from its frame. */
+export const APPROVAL_AUDIT_ACTIONS: Record<string, string> = {
+  install_packages: 'self-mod.install-packages',
+  add_mcp_server: 'self-mod.add-mcp-server',
+  create_agent: 'agents.create',
+  a2a_message_gate: 'messages.a2a-gate',
+  onecli_credential: 'onecli.credential.use',
+};
+
+export function auditActionForApproval(approvalAction: string, payload: Record<string, unknown>): string {
+  if (approvalAction === 'cli_command') {
+    const frame = payload.frame as RequestFrame | undefined;
+    return (frame && lookup(frame.command)?.action) ?? 'cli.unknown-command';
+  }
+  return APPROVAL_AUDIT_ACTIONS[approvalAction] ?? approvalAction.replace(/_/g, '.');
+}
+
+/**
+ * details for an approval's pending/terminal events. Message-bearing payloads
+ * (a2a gate) record shape only — body_chars and attachment names, never
+ * content; the emit-seam redactor is defense-in-depth, not the mechanism.
+ */
+export function detailsForApprovalPayload(
+  approvalAction: string,
+  payload: Record<string, unknown>,
+): Record<string, unknown> {
+  switch (approvalAction) {
+    case 'cli_command': {
+      const frame = payload.frame as RequestFrame | undefined;
+      return { ...(frame?.args ?? {}) };
+    }
+    case 'create_agent': {
+      const instructions = typeof payload.instructions === 'string' ? payload.instructions : null;
+      return { name: payload.name, instructions_chars: instructions ? instructions.length : 0 };
+    }
+    case 'a2a_message_gate': {
+      const { text, files } = messageShape(payload.content);
+      return { to: payload.platform_id, body_chars: text.length, attachments: files };
+    }
+    default:
+      // install_packages, add_mcp_server, and future types: metadata payloads
+      // pass through as-is — the emit-seam redactor masks sensitive keys.
+      return { ...payload };
+  }
+}
+
+export function resourcesForApproval(
+  approvalAction: string,
+  payload: Record<string, unknown>,
+  session: Session,
+): AuditResource[] {
+  const base: AuditResource[] = [{ type: 'agent_group', id: session.agent_group_id }];
+  if (approvalAction === 'cli_command') {
+    const frame = payload.frame as RequestFrame | undefined;
+    const cmd = frame && lookup(frame.command);
+    if (cmd && frame) {
+      const cliResources = resourcesForCli(cmd, frame.args);
+      for (const r of cliResources) {
+        if (!base.some((b) => b.type === r.type && b.id === r.id)) base.push(r);
+      }
+    }
+  }
+  if (approvalAction === 'a2a_message_gate' && typeof payload.platform_id === 'string' && payload.platform_id) {
+    if (payload.platform_id !== session.agent_group_id) {
+      base.push({ type: 'agent_group', id: payload.platform_id });
+    }
+  }
+  return base;
+}
+
+// ── OneCLI credential approvals ──
+
+/** = APPROVAL_AUDIT_ACTIONS.onecli_credential; named for the OneCLI wrappers. */
+export const ONECLI_AUDIT_ACTION = 'onecli.credential.use';
+
+interface OneCliRowShape {
+  approval_id: string;
+  agent_group_id?: string | null;
+  payload: string;
+}
+
+interface OneCliPayload {
+  oneCliRequestId?: string;
+  method?: string;
+  host?: string;
+  path?: string;
+  bodyPreview?: string;
+  agent?: { externalId?: string | null; name?: string };
+  approver?: string;
+}
+
+function oneCliPayload(row: OneCliRowShape): OneCliPayload {
+  try {
+    const parsed: unknown = JSON.parse(row.payload);
+    return parsed && typeof parsed === 'object' ? (parsed as OneCliPayload) : {};
+    // eslint-disable-next-line no-catch-all/no-catch-all -- stored payloads are untrusted; a malformed one must not break event assembly
+  } catch {
+    return {};
+  }
+}
+
+/** Shape-only: the request body's presence is auditable, its content never is. */
+function oneCliDetails(p: OneCliPayload): Record<string, unknown> {
+  return {
+    method: p.method,
+    host: p.host,
+    path: p.path,
+    one_cli_request_id: p.oneCliRequestId,
+    body_preview_chars: typeof p.bodyPreview === 'string' ? p.bodyPreview.length : 0,
+  };
+}
+
+function oneCliResources(row: OneCliRowShape): AuditResource[] {
+  const out: AuditResource[] = [];
+  if (row.agent_group_id) out.push({ type: 'agent_group', id: row.agent_group_id });
+  out.push({ type: 'approval', id: row.approval_id });
+  return out;
+}
+
+/** Pending event for a OneCLI credential hold, derived from its row. */
+export function oneCliHoldEvent(row: OneCliRowShape): AuditEventInput {
+  const p = oneCliPayload(row);
+  const resources = oneCliResources(row);
+  if (p.approver) resources.push({ type: 'user', id: p.approver });
+  return {
+    actor: { type: 'agent', id: row.agent_group_id ?? p.agent?.externalId ?? p.agent?.name ?? 'unknown' },
+    // OneCLI requests come from inside an agent container but carry no session.
+    origin: { transport: 'container' },
+    action: ONECLI_AUDIT_ACTION,
+    resources,
+    outcome: 'pending',
+    correlationId: row.approval_id,
+    details: oneCliDetails(p),
+  };
+}
+
+/** approvals.decide for a OneCLI resolution (click, expiry, or startup sweep). */
+export function oneCliDecideEvent(
+  row: OneCliRowShape & { channel_type?: string | null },
+  args: { actor: AuditActor; origin: AuditOrigin; outcome: 'approved' | 'rejected'; reason?: string },
+): AuditEventInput {
+  const details: Record<string, unknown> = {
+    gated_action: ONECLI_AUDIT_ACTION,
+    ...oneCliDetails(oneCliPayload(row)),
+  };
+  if (args.reason) details.reason = args.reason;
+  return {
+    actor: args.actor,
+    origin: args.origin,
+    action: 'approvals.decide',
+    resources: oneCliResources(row),
+    outcome: args.outcome,
+    correlationId: row.approval_id,
+    details,
+  };
+}
+
+/** Mirror of agent-route's message-content parse — shape extraction only. */
+function messageShape(content: unknown): { text: string; files: string[] } {
+  if (typeof content !== 'string') return { text: '', files: [] };
+  try {
+    const parsed = JSON.parse(content) as { text?: unknown; files?: unknown };
+    return {
+      text: typeof parsed.text === 'string' ? parsed.text : '',
+      files: Array.isArray(parsed.files) ? parsed.files.filter((f): f is string => typeof f === 'string') : [],
+    };
+    // eslint-disable-next-line no-catch-all/no-catch-all -- non-JSON content is the raw body; shape extraction must not throw
+  } catch {
+    return { text: content, files: [] };
+  }
+}

src/audit/observer.ts

@@ -0,0 +1,48 @@
+/**
+ * Decision events — approvals.decide, one per resolved approval, riding the
+ * existing approval-resolved hook. Covers every requestApproval-backed action
+ * (cli_command, self-mod, create_agent, a2a gate); OneCLI never reaches
+ * notifyApprovalResolved and emits its decisions from its own wrappers.
+ */
+// Direct file import (not the approvals barrel) to keep the graph tight.
+import { type ApprovalResolvedEvent, registerApprovalResolvedHandler } from '../modules/approvals/primitive.js';
+import { emitAuditEvent } from './emit.js';
+import { auditActionForApproval, channelOriginForUser, humanOrSystemActor, resourcesForApproval } from './mapping.js';
+
+export function onApprovalResolved(event: ApprovalResolvedEvent): void {
+  emitAuditEvent(() => {
+    const payload = safeParse(event.approval.payload);
+    return {
+      // '' resolver = sweep/timer (e.g. the awaiting-reason ghost sweep) → system.
+      actor: humanOrSystemActor(event.userId),
+      // Decisions are card clicks on a chat platform, even system-finalized
+      // ones — the card lifecycle is the surface.
+      origin: channelOriginForUser(event.userId),
+      action: 'approvals.decide',
+      resources: [
+        ...resourcesForApproval(event.approval.action, payload, event.session),
+        { type: 'approval', id: event.approval.approval_id },
+      ],
+      outcome: event.outcome === 'approve' ? 'approved' : 'rejected',
+      correlationId: event.approval.approval_id,
+      details: {
+        gated_action: auditActionForApproval(event.approval.action, payload),
+        requested_by: event.session.agent_group_id,
+      },
+    };
+  });
+}
+
+export function registerAuditObserver(): void {
+  registerApprovalResolvedHandler(onApprovalResolved);
+}
+
+function safeParse(json: string): Record<string, unknown> {
+  try {
+    const parsed: unknown = JSON.parse(json);
+    return parsed && typeof parsed === 'object' ? (parsed as Record<string, unknown>) : {};
+    // eslint-disable-next-line no-catch-all/no-catch-all -- stored payloads are untrusted; a malformed one must not break the decision event
+  } catch {
+    return {};
+  }
+}

src/audit/reader.test.ts

@@ -10,9 +10,6 @@ vi.mock('../config.js', () => ({
   get DATA_DIR() {
     return state.dataDir;
   },
-}));
-
-vi.mock('./config.js', () => ({
   get AUDIT_ENABLED() {
     return state.enabled;
   },

src/audit/reader.ts

@@ -6,8 +6,8 @@
 import fs from 'fs';
 import path from 'path';
 
+import { AUDIT_ENABLED } from '../config.js';
 import { log } from '../log.js';
-import { AUDIT_ENABLED } from './config.js';
 import { AUDIT_DIR, utcDay } from './store.js';
 import type { AuditEvent, AuditOutcome } from './types.js';
 

src/audit/redact.ts

@@ -1,8 +1,13 @@
 /**
- * The one redactor, applied to every event's `details` at the emit seam —
- * guarding current and future surfaces by default. Key-pattern mask plus a
- * per-value size cap; message bodies are never passed in (emit sites record
- * shape only — the audit log is a governance record, not a chat archive).
+ * Recursive details redaction — runs at the single emit seam so every current
+ * and future surface is guarded by default. Two rules:
+ *   1. Any key matching the sensitive pattern is masked to '[REDACTED]'
+ *      (the value is never inspected or recursed into).
+ *   2. Strings are truncated to ~2 KB post-redaction.
+ *
+ * Message bodies are excluded upstream by the per-surface mappers (shape only:
+ * body_chars, attachment names) — this mask is defense-in-depth, not the
+ * mechanism that keeps chat content out of the log.
  */
 
 const SENSITIVE_KEY = /(token|secret|key|password|credential|auth|bearer)/i;
@@ -26,6 +31,8 @@ function redactValue(value: unknown, depth: number): unknown {
     return value.length > MAX_VALUE_CHARS ? `${value.slice(0, MAX_VALUE_CHARS)}…[truncated]` : value;
   }
   if (value === null || typeof value !== 'object') return value;
+  // Depth cap doubles as a cheap cycle guard — details payloads are
+  // JSON-serializable in practice, but the emit path must never throw.
   if (depth > MAX_DEPTH) return '[MAX_DEPTH]';
   if (Array.isArray(value)) return value.map((v) => redactValue(v, depth + 1));
   return redactObject(value as Record<string, unknown>, depth);

src/audit/store.test.ts

@@ -4,18 +4,14 @@ import path from 'path';
 
 import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest';
 
-// Core config (DATA_DIR) and the audit config (toggles) are mocked so
-// store/emit resolve a per-test temp DATA_DIR and audit switches. Getters
-// keep the values live across vi.resetModules().
+// Config + log are mocked so store/emit resolve a per-test temp DATA_DIR and
+// audit toggles. Getters keep the values live across vi.resetModules().
 const state = vi.hoisted(() => ({ dataDir: '', enabled: true, retention: 90 }));
 
 vi.mock('../config.js', () => ({
   get DATA_DIR() {
     return state.dataDir;
   },
-}));
-
-vi.mock('./config.js', () => ({
   get AUDIT_ENABLED() {
     return state.enabled;
   },