@vellumai/assistant 0.4.56 → 0.4.57

package/ARCHITECTURE.md

@@ -4,11 +4,11 @@ This document owns assistant-runtime architecture details. The repo-level archit
 
 ### Channel Onboarding Playbook Bootstrap
 
-- Transport metadata arrives via `session_create.transport` (HTTP) or `/channels/inbound` (`channelId`, optional `hints`, optional `uxBrief`).
+- Transport metadata arrives via `conversation_create.transport` (HTTP) or `/channels/inbound` (`channelId`, optional `hints`, optional `uxBrief`).
 - Telegram webhook ingress injects deterministic channel-safe transport metadata (`hints` + `uxBrief`) so non-dashboard channels defer dashboard-only UI tasks cleanly.
 - `OnboardingPlaybookManager` resolves `<channel>_onboarding.md`, checks `onboarding/playbooks/registry.json`, and applies per-channel first-time fast-path onboarding.
 - `OnboardingOrchestrator` derives onboarding-mode guidance (post-hatch sequence, USER.md capture) from playbook + transport context.
-- Session runtime assembly injects both `<channel_onboarding_playbook>` and `<onboarding_mode>` context before provider calls, then strips both from persisted conversation history.
+- Conversation runtime assembly injects both `<channel_onboarding_playbook>` and `<onboarding_mode>` context before provider calls, then strips both from persisted conversation history.
 - Permission setup remains user-initiated and hatch + first-conversation flows avoid proactive permission asks.
 
 ### Guardian Actor Context (Unified Across Channels)
@@ -17,7 +17,7 @@ This document owns assistant-runtime architecture details. The repo-level archit
 - The same resolver is used by:
   - `/channels/inbound` (Telegram/WhatsApp path) before run orchestration.
   - Inbound Twilio voice setup (`RelayConnection.handleSetup`) to seed call-time actor context.
-- Runtime channel runs pass this as `trustContext`, and session runtime assembly injects `<inbound_actor_context>` (via `inboundActorContextFromTrustContext()`) into provider-facing prompts.
+- Runtime channel runs pass this as `trustContext`, and conversation runtime assembly injects `<inbound_actor_context>` (via `inboundActorContextFromTrustContext()`) into provider-facing prompts.
 - Voice calls mirror the same prompt contract: `CallController` receives guardian context on setup and refreshes it immediately after successful voice challenge verification, so the first post-verification turn is grounded as `actor_role: guardian`.
 - Voice-specific behavior (DTMF/speech verification flow, relay state machine) remains voice-local; only actor-role resolution is shared.
 
@@ -138,7 +138,7 @@ All guardian approval decisions — regardless of how they arrive — route thro
 | `src/runtime/routes/guardian-action-routes.ts` | HTTP route handlers for `GET /v1/guardian-actions/pending` and `POST /v1/guardian-actions/decision`                                               |
 | `src/runtime/channel-approval-types.ts`        | Channel-facing approval action types and `toApprovalActionOptions` bridge                                                                         |
 
-### Temporary Approval Modes (Session-Scoped Overrides)
+### Temporary Approval Modes (Conversation-Scoped Overrides)
 
 In addition to persistent trust rules (`always_allow` / `always_deny`), the approval system supports two **temporary** approval modes that auto-approve tool confirmations for the duration of a conversation or a fixed time window. These exist to reduce prompt fatigue during intensive sessions without permanently altering the trust configuration.
 
@@ -147,7 +147,7 @@ In addition to persistent trust rules (`always_allow` / `always_deny`), the appr
 1. **`allow_conversation`** — Auto-approve all tool confirmations for the remainder of the current conversation. The override persists until the session ends, the conversation is closed, or the mode is explicitly cleared.
 2. **`allow_10m`** — Auto-approve all tool confirmations for 10 minutes (configurable). The override expires lazily on the next read after the TTL elapses — no background sweep runs.
 
-**Session-scoped, in-memory only:** Overrides are keyed by `conversationId` and stored in an in-memory `Map` inside `conversation-approval-overrides.ts`. They do not survive daemon restarts, which is intentional — temporary approvals should not outlive the session that created them.
+**Conversation-scoped, in-memory only:** Overrides are keyed by `conversationId` and stored in an in-memory `Map` inside `conversation-approval-overrides.ts`. They do not survive daemon restarts, which is intentional — temporary approvals should not outlive the conversation that created them.
 
 **Integration with the permission pipeline:** The permission checker (`src/tools/permission-checker.ts`) checks for an active temporary override via `getEffectiveMode()` before prompting the user. If an active override exists for the current conversation, the confirmation is auto-approved without surfacing a prompt. This check runs after persistent trust rules, so a persistent `deny` rule still takes precedence.
 
@@ -783,10 +783,10 @@ All client-server communication uses HTTP for request/response operations and Se
 
 The daemon emits two distinct error message types via SSE:
 
-| Message type         | Scope          | Purpose                                                                                                        | Payload                                                                       |
-| -------------------- | -------------- | -------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
-| `conversation_error` | Session-scoped | Typed, actionable failures during chat/session runtime (e.g., provider network error, rate limit, API failure) | `sessionId`, `code` (typed enum), `userMessage`, `retryable`, `debugDetails?` |
-| `error`              | Global         | Generic, non-session failures (e.g., daemon startup errors, unknown message types)                             | `message` (string)                                                            |
+| Message type         | Scope               | Purpose                                                                                                        | Payload                                                                       |
+| -------------------- | ------------------- | -------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
+| `conversation_error` | Conversation-scoped | Typed, actionable failures during conversation runtime (e.g., provider network error, rate limit, API failure) | `sessionId`, `code` (typed enum), `userMessage`, `retryable`, `debugDetails?` |
+| `error`              | Global              | Generic, non-session failures (e.g., daemon startup errors, unknown message types)                             | `message` (string)                                                            |
 
 **Design rationale:** `conversation_error` carries structured metadata (error code, retryable flag, debug details) so the client can present actionable UI — a toast with retry/dismiss buttons — rather than a generic error banner. The older `error` type is retained for backward compatibility with non-session contexts.
 
@@ -845,7 +845,7 @@ sequenceDiagram
     end
 ```
 
-1. **Daemon** encounters a session-scoped failure, classifies it via `classifyConversationError()`, and sends a `conversation_error` SSE event with the session ID, typed error code, user-facing message, retryable flag, and optional debug details. Session-scoped failures emit _only_ `conversation_error` (never the generic `error` type) to prevent cross-session bleed.
+1. **Daemon** encounters a conversation-scoped failure, classifies it via `classifyConversationError()`, and sends a `conversation_error` SSE event with the conversation ID, typed error code, user-facing message, retryable flag, and optional debug details. Conversation-scoped failures emit _only_ `conversation_error` (never the generic `error` type) to prevent cross-conversation bleed.
 2. **ChatViewModel** receives the error via DaemonClient's `subscribe()` stream (each view model gets an independent stream), sets the `conversationError` property, and transitions out of the streaming/loading state so the UI is interactive. If the error arrives during an active cancel (`wasCancelling == true`), it is suppressed — cancel only shows `generation_cancelled` behavior.
 3. **ChatView** observes the published `conversationError` and displays an actionable toast with a category-specific icon and accent color:
    - **Retry** (shown when `retryable` is true): calls `retryAfterConversationError()`, which clears the error and sends a `regenerate` message to the daemon.

package/Dockerfile

@@ -89,6 +89,9 @@ RUN echo 'Dir::State "/data/dpkg";' > /etc/apt/apt.conf.d/99data-dir && \
 ENV PATH="/data/usr/bin:/data/usr/sbin:${PATH}"
 ENV LD_LIBRARY_PATH="/data/usr/lib:/data/usr/lib/x86_64-linux-gnu:/data/usr/lib/aarch64-linux-gnu"
 
+# Ensure the CES bootstrap socket volume is writable by the non-root CES user.
+RUN mkdir -p /run/ces-bootstrap && chmod 777 /run/ces-bootstrap
+
 USER root
 
 EXPOSE 3001

package/README.md

@@ -77,17 +77,17 @@ bun run src/index.ts                # interactive CLI session
 
 ### CLI commands
 
-| Command                                       | Description                                      |
-| --------------------------------------------- | ------------------------------------------------ |
-| `vellum wake`                                 | Start assistant + gateway from current checkout  |
-| `vellum sleep`                                | Stop assistant + gateway processes               |
-| `vellum ps`                                   | List assistants and per-assistant process status |
-| `assistant`                                   | Launch interactive CLI session                   |
-| `assistant sessions list\|new\|export\|clear` | Manage conversation sessions                     |
-| `assistant config set\|get\|list`             | Manage configuration                             |
-| `assistant keys set\|list\|delete`            | Manage API keys in secure storage                |
-| `assistant trust list\|remove\|clear`         | Manage trust rules                               |
-| `assistant doctor`                            | Run diagnostic checks                            |
+| Command                                            | Description                                      |
+| -------------------------------------------------- | ------------------------------------------------ |
+| `vellum wake`                                      | Start assistant + gateway from current checkout  |
+| `vellum sleep`                                     | Stop assistant + gateway processes               |
+| `vellum ps`                                        | List assistants and per-assistant process status |
+| `assistant`                                        | Launch interactive CLI session                   |
+| `assistant conversations list\|new\|export\|clear` | Manage conversations                             |
+| `assistant config set\|get\|list`                  | Manage configuration                             |
+| `assistant keys set\|list\|delete`                 | Manage API keys in secure storage                |
+| `assistant trust list\|remove\|clear`              | Manage trust rules                               |
+| `assistant doctor`                                 | Run diagnostic checks                            |
 
 ## Project Structure
 

package/docs/architecture/integrations.md

@@ -542,7 +542,7 @@ sequenceDiagram
     Materialize->>DB: load attachment (including base64 data)
     Materialize->>Visibility: isAttachmentVisible(attachmentCtx, currentCtx)
     Note over Visibility: Second visibility check at materialize time<br/>prevents TOCTOU between search and materialize
-    Materialize->>Materialize: size check (max 50 MB)
+    Materialize->>Materialize: size check (max 100 MB)
     Materialize->>Sandbox: write decoded bytes to destination
     Materialize-->>Model: "Materialized 'photo.jpg' to /workspace/media/photo.jpg"
 ```
@@ -586,7 +586,7 @@ graph TB
 ### Materialize Safeguards
 
 - **Sandbox path enforcement**: Destination path must resolve inside the sandbox working directory
-- **Size limit**: 50 MB ceiling prevents materializing excessively large attachments
+- **Size limit**: 100 MB ceiling prevents materializing excessively large attachments
 - **Double visibility check**: Both `asset_search` and `asset_materialize` independently verify visibility, preventing TOCTOU races between search and use
 - **Risk level**: Both tools are `RiskLevel.Low` since they read existing data and write only within the sandbox
 

package/docs/architecture/memory.md

@@ -250,7 +250,7 @@ The recall pipeline runs on every turn that passes the `needsMemory` gate (skips
 9. **Two-layer XML injection** (`formatting.ts`): Budget-aware rendering into four XML sections:
 
    ```xml
-   <memory_context>
+   <memory_context __injected>
 
    <user_identity>
    <!-- identity-kind tier 1 items (plain statements) -->
@@ -273,7 +273,7 @@ The recall pipeline runs on every turn that passes the `needsMemory` gate (skips
 
    Empty sections are omitted. Each section has a per-item token budget (150 tokens for tier 1, 100 for tier 2). Tier 1 sections consume budget first; tier 2 uses the remainder.
 
-10. **Injection strategy**: The rendered `<memory_context>` block is injected as a separate user + assistant acknowledgment message pair before the last user message (`injectMemoryRecallAsSeparateMessage`). This separates memory context from the user's actual query.
+10. **Injection strategy**: The rendered `<memory_context __injected>` block is prepended as a text content block to the last user message (`injectMemoryRecallAsUserBlock`), following the same pattern as workspace, temporal, and other runtime injections. Stripping is handled by the generic `stripUserTextBlocksByPrefix` mechanism matching the `<memory_context __injected>` prefix (with a backward-compat entry for the legacy `<memory_context>` prefix from older history). This avoids synthetic message pairs and preserves prompt prefix caching between turns.
 
 ### Internal-Only Trust Gating
 
@@ -464,7 +464,7 @@ The Anthropic provider places `cache_control: { type: 'ephemeral' }` on the **la
 
 ## Temporal Context Injection — Date Grounding
 
-The session injects a `<temporal_context>` block into every user message at runtime, giving the model awareness of the current date, current local time, current UTC time, timezone source metadata, upcoming weekend/work week windows, and a 14-day horizon of labelled future dates. This enables reliable reasoning about future dates (e.g. "plan a trip for next weekend") without persisting volatile temporal data in conversation history.
+The session injects a `<temporal_context>` block into every user message at runtime, giving the model awareness of the current date, current local time, current UTC time, and timezone source metadata. This enables reliable reasoning about dates and times without persisting volatile temporal data in conversation history.
 
 ### Per-turn flow
 
@@ -488,7 +488,6 @@ graph TB
 - **Clock source invariant**: Absolute time (`now`) always comes from the assistant host clock (`Date.now()`), never from channel/client clocks.
 - **Timezone precedence**: If `ui.userTimezone` is configured, temporal context uses it for local-date interpretation. Otherwise it falls back to memory-stored timezone, then assistant host timezone.
 - **Timezone-aware**: Uses `Intl.DateTimeFormat` APIs for DST-safe date arithmetic and timezone validation/canonicalization.
-- **Bounded output**: Hard-capped at 1500 characters and 14 horizon entries to prevent prompt bloat.
 - **Runtime-only**: The injected `<temporal_context>` block is stripped from `this.messages` after the agent loop completes via `stripTemporalContext`. It never persists in conversation history.
 - **Specific strip prefix**: The strip function matches the exact injected prefix (`<temporal_context>\nToday:`) to avoid accidentally removing user-authored text that starts with `<temporal_context>`.
 - **Retry paths**: Temporal context is included in all three `applyRuntimeInjections` call sites (main path, compact retry, media-trim retry).

package/docs/credential-execution-service.md

@@ -60,36 +60,29 @@ The existing `host_bash` tool executes commands on the host machine without any
 
 **Implication**: `host_bash` represents a weaker security tier. Agents that require the strong secrecy guarantee must use `run_authenticated_command` instead. Trust rules and permission policies should reflect this distinction — managed deployments may deny `host_bash` entirely for untrusted agents while allowing `run_authenticated_command`.
 
-### 2. Local static secrets are local-mode only — by design
+### 2. Local static secrets are local-mode only — by policy
 
-For the initial implementation, local static secrets (API keys, tokens stored via the credential store in `~/.vellum/protected/`) are only accessible to CES in **local mode**, where CES runs as a child process of the assistant as the same OS user. CES reads them at materialization time via direct filesystem access.
+For the current implementation, local static secrets (API keys, tokens stored via the credential store in `~/.vellum/protected/`) are only accessible to CES in **local mode**, where CES runs as a child process of the assistant. CES reads them at materialization time via direct filesystem access.
 
-In **managed mode**, `local_static` handles are not supported and the CES returns a clear error for any `local_static` handle. Managed deployments use `platform_oauth` handles exclusively. This is a deliberate architectural decision, not a temporary limitation.
+In **managed mode**, `local_static` handles are not supported and the CES returns a clear error for any `local_static` handle. Managed deployments use `platform_oauth` handles exclusively. With v2 `store.key`, this is a **policy choice** (simpler lifecycle, centralized token management) rather than a technical limitation — the UID-independent key file could be shared via volume mount.
 
-#### Why `local_static` cannot work in managed mode
+#### Historical: v1 key derivation blocker (resolved in v2)
 
-The original design considered having managed deployments share static secrets via the assistant data volume. This is technically impossible due to how the encrypted key store works.
+The v1 encrypted key store uses PBKDF2 key derivation where the encryption key is derived from `userInfo().username` and `userInfo().homedir`. In managed deployments the assistant and CES sidecar run as different OS users, producing different derived keys — making it impossible for CES to decrypt secrets stored by the assistant.
 
-The `local-secure-key-backend.ts` module uses PBKDF2 key derivation where the encryption key is derived from `userInfo().username` and `userInfo().homedir`. In managed deployments:
+v2 stores replaced PBKDF2 derivation with a random 32-byte key stored at `<vellumRoot>/protected/store.key`. This key is UID-independent and can be shared via volume mount, removing the technical barrier to `local_static` in managed mode.
 
-- The **assistant container** runs as `root` (homedir `/root`)
-- The **CES sidecar container** runs as `ces` / uid 1001 (homedir `/home/ces`)
+The policy decision to use `platform_oauth` exclusively in managed mode still stands for operational reasons: simpler credential lifecycle, centralized token management, and no need to synchronize key files across containers. Future iterations may enable `local_static` in managed mode via shared `store.key` volume mounts if there is a compelling use case.
 
-These produce different PBKDF2-derived AES keys. Even if the encrypted key store file (`keys.enc`) were mounted as a shared volume, CES would derive a different decryption key and silently fail to decrypt the secrets.
+#### Rejected alternatives (v1-era, historical context)
 
-#### Rejected alternatives
+These alternatives were evaluated for the v1 key store and rejected. They are retained for historical context — the v2 `store.key` format resolves the underlying issue without hitting these trade-offs.
 
-Three alternatives were evaluated and rejected because each breaks a core security invariant:
+1. **Mount decrypted secrets into the CES container** — Breaks the "secrets never in assistant process memory" boundary (Boundary Invariant #2).
 
-1. **Mount decrypted secrets into the CES container** — This would require decrypting secrets in the assistant container and writing plaintext to a shared volume, breaking the "secrets never in assistant process memory" boundary (Boundary Invariant #2).
+2. **Use shared key derivation independent of UID** — Was rejected for v1 because it weakened the encrypted-at-rest model. The v2 `store.key` approach achieves UID-independent decryption without the per-user identity trade-off, since the random key file is protected by filesystem permissions rather than derivation entropy.
 
-2. **Use shared key derivation independent of UID** — Deriving the encryption key from a shared secret (e.g., a pod-level token) rather than per-user identity would weaken the encrypted-at-rest security model. The UID-based derivation ensures that only the user who stored the credential can decrypt it, which is a fundamental property of the local credential store.
-
-3. **Pre-decrypt and pass via the RPC socket** — Having the assistant decrypt the secret and send it to CES over the Unix socket would mean the assistant process handles plaintext credential values, directly violating the CES process-boundary isolation guarantee.
-
-Since all alternatives break security invariants that CES exists to enforce, managed deployments route credential access through `platform_oauth` where the platform manages token lifecycle and CES requests materialized tokens via the platform proxy endpoint.
-
-Future iterations may move secret storage to a dedicated secret manager (e.g., cloud KMS, Vault) with CES as the only authorized reader, which would enable static secrets in managed mode without compromising the process-boundary isolation.
+3. **Pre-decrypt and pass via the RPC socket** — Violates the CES process-boundary isolation guarantee.
 
 ### 3. Platform OAuth materialization stays on the platform
 
@@ -396,7 +389,7 @@ This means the helper is subject to the same cooperative egress limitation as th
 
 The following capabilities are intentionally deferred beyond v1:
 
-- **`local_static` handles in managed mode** — Structurally unsupported due to PBKDF2 key derivation depending on per-container UID (see Locked Decision #2 for full rationale and rejected alternatives). Managed mode returns a clear error and requires `platform_oauth` handles exclusively.
+- **`local_static` handles in managed mode** — Technically feasible with v2 `store.key` (UID-independent), but managed mode currently uses `platform_oauth` exclusively as a policy choice (see Locked Decision #2). May be enabled in the future via shared `store.key` volume mount if there is a compelling use case.
 - **Cloud KMS/Vault integration for secret storage** — v1 reads secrets from filesystem (`~/.vellum/protected/` locally, `/ces-data` in managed). Moving to a dedicated secrets manager is a future enhancement.
 - **Multi-CES-instance support** — Each assistant pod runs exactly one CES sidecar. Horizontal scaling of CES within a pod is not supported.
 - **Cross-pod credential sharing** — CES grants are scoped to a single pod. There is no grant federation across pods or assistant instances.

package/node_modules/@vellumai/ces-contracts/src/error.ts

@@ -15,10 +15,11 @@ export type RpcError = z.infer<typeof RpcErrorSchema>;
 
 /**
  * Error returned when a local_static credential handle is used in managed
- * mode. The encrypted key store uses PBKDF2 key derivation from user
- * identity (username, homedir), but the assistant container runs as root
- * while CES runs as ces — different derived keys make decryption silently
- * fail. Managed deployments must use platform_oauth handles exclusively.
+ * mode. v2 stores use a UID-independent `store.key` file that removes the
+ * technical barrier (legacy v1 relied on PBKDF2 key derivation from user
+ * identity, which broke across container users). The restriction is now a
+ * policy choice: managed deployments use platform_oauth handles exclusively
+ * for simpler lifecycle and centralized token management.
  */
 export const MANAGED_LOCAL_STATIC_REJECTION_ERROR =
   "local_static credential handles are not supported in managed mode. " +

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vellumai/assistant",
-  "version": "0.4.56",
+  "version": "0.4.57",
   "type": "module",
   "exports": {
     ".": "./src/index.ts"

package/src/__tests__/actor-token-service.test.ts

@@ -93,8 +93,8 @@ function mockServer(address: string): ServerWithRequestIP {
 /** Mock loopback server -- returns 127.0.0.1 for all requests. */
 const loopbackServer = mockServer("127.0.0.1");
 
-/** Mock non-loopback server -- returns a LAN IP for all requests. */
-const nonLoopbackServer = mockServer("192.168.1.50");
+/** Mock non-loopback server -- returns a public IP for all requests. */
+const nonLoopbackServer = mockServer("203.0.113.50");
 
 initializeDb();
 
@@ -676,11 +676,11 @@ describe("pairing credential flow", () => {
 });
 
 // ---------------------------------------------------------------------------
-// Bootstrap loopback guard tests
+// Bootstrap private-network guard tests
 // ---------------------------------------------------------------------------
 
-describe("bootstrap loopback guard", () => {
-  test("rejects bootstrap request with X-Forwarded-For header", async () => {
+describe("bootstrap private-network guard", () => {
+  test("rejects bootstrap request with public X-Forwarded-For", async () => {
     const { handleGuardianBootstrap } =
       await import("../runtime/routes/guardian-bootstrap-routes.js");
 
@@ -688,7 +688,7 @@ describe("bootstrap loopback guard", () => {
       method: "POST",
       headers: {
         "Content-Type": "application/json",
-        "X-Forwarded-For": "10.0.0.1",
+        "X-Forwarded-For": "203.0.113.1",
       },
       body: JSON.stringify({ platform: "macos", deviceId: "test-device" }),
     });
@@ -699,7 +699,7 @@ describe("bootstrap loopback guard", () => {
     expect(body.error.message).toContain("local-only");
   });
 
-  test("rejects bootstrap request from non-loopback IP", async () => {
+  test("rejects bootstrap request from public IP peer", async () => {
     const { handleGuardianBootstrap } =
       await import("../runtime/routes/guardian-bootstrap-routes.js");
 

package/src/__tests__/anthropic-provider.test.ts

@@ -62,6 +62,7 @@ mock.module("@anthropic-ai/sdk", () => ({
 }));
 
 // Import after mocking
+import { SYSTEM_PROMPT_CACHE_BOUNDARY } from "../prompts/system-prompt.js";
 import {
   AnthropicProvider,
   PLACEHOLDER_BLOCKS_OMITTED,
@@ -155,6 +156,25 @@ describe("AnthropicProvider — Cache-Control Characterization", () => {
     expect(lastStreamParams!.system).toBeUndefined();
   });
 
+  test("splits system prompt into two cache blocks on boundary marker", async () => {
+    const staticBlock = "You are a helpful assistant.";
+    const dynamicBlock = "User workspace files here.";
+    const prompt = staticBlock + SYSTEM_PROMPT_CACHE_BOUNDARY + dynamicBlock;
+
+    await provider.sendMessage([userMsg("Hi")], undefined, prompt);
+
+    const system = lastStreamParams!.system as Array<{
+      type: string;
+      text: string;
+      cache_control?: { type: string };
+    }>;
+    expect(system).toHaveLength(2);
+    expect(system[0].text).toBe(staticBlock);
+    expect(system[0].cache_control).toEqual({ type: "ephemeral" });
+    expect(system[1].text).toBe(dynamicBlock);
+    expect(system[1].cache_control).toEqual({ type: "ephemeral" });
+  });
+
   // -----------------------------------------------------------------------
   // Tool cache control
   // -----------------------------------------------------------------------
@@ -1307,6 +1327,158 @@ describe("AnthropicProvider — Cache-Control Characterization", () => {
     expect(userMsgs[2].content[0].cache_control).toBeUndefined();
     expect(userMsgs[2].content[1].cache_control).toBeUndefined();
   });
+
+  // -----------------------------------------------------------------------
+  // is_error + contentBlocks — non-text blocks must be stripped
+  // -----------------------------------------------------------------------
+
+  test("is_error tool_result strips non-text contentBlocks (images)", async () => {
+    const messages: Message[] = [
+      userMsg("Do something"),
+      toolUseMsg("tu_img", "file_read"),
+      {
+        role: "user",
+        content: [
+          {
+            type: "tool_result",
+            tool_use_id: "tu_img",
+            content: "Error: file not found",
+            is_error: true,
+            contentBlocks: [
+              {
+                type: "image",
+                source: {
+                  type: "base64",
+                  media_type: "image/png",
+                  data: "iVBOR",
+                },
+              },
+              { type: "text", text: "extra error detail" },
+            ],
+          },
+        ],
+      },
+    ];
+    await provider.sendMessage(messages);
+
+    const sent = lastStreamParams!.messages as Array<{
+      role: string;
+      content: Array<{
+        type: string;
+        tool_use_id?: string;
+        is_error?: boolean;
+        content?: unknown;
+      }>;
+    }>;
+
+    const toolResult = sent[2].content.find(
+      (b) => b.type === "tool_result" && b.tool_use_id === "tu_img",
+    )!;
+    expect(toolResult.is_error).toBe(true);
+
+    // Content should be an array with only text blocks (no images)
+    const parts = toolResult.content as Array<{ type: string }>;
+    expect(Array.isArray(parts)).toBe(true);
+    expect(parts.every((p) => p.type === "text")).toBe(true);
+    // Original text + the extra text contentBlock
+    expect(parts).toHaveLength(2);
+  });
+
+  test("is_error tool_result with only image contentBlocks falls back to text-only", async () => {
+    const messages: Message[] = [
+      userMsg("Do something"),
+      toolUseMsg("tu_img2", "file_read"),
+      {
+        role: "user",
+        content: [
+          {
+            type: "tool_result",
+            tool_use_id: "tu_img2",
+            content: "Error: file not found",
+            is_error: true,
+            contentBlocks: [
+              {
+                type: "image",
+                source: {
+                  type: "base64",
+                  media_type: "image/png",
+                  data: "iVBOR",
+                },
+              },
+            ],
+          },
+        ],
+      },
+    ];
+    await provider.sendMessage(messages);
+
+    const sent = lastStreamParams!.messages as Array<{
+      role: string;
+      content: Array<{
+        type: string;
+        tool_use_id?: string;
+        is_error?: boolean;
+        content?: unknown;
+      }>;
+    }>;
+
+    const toolResult = sent[2].content.find(
+      (b) => b.type === "tool_result" && b.tool_use_id === "tu_img2",
+    )!;
+    expect(toolResult.is_error).toBe(true);
+
+    // All images stripped → no usable blocks → falls back to text-only content
+    expect(toolResult.content).toBe("Error: file not found");
+  });
+
+  test("non-error tool_result preserves image contentBlocks", async () => {
+    const messages: Message[] = [
+      userMsg("Do something"),
+      toolUseMsg("tu_img3", "file_read"),
+      {
+        role: "user",
+        content: [
+          {
+            type: "tool_result",
+            tool_use_id: "tu_img3",
+            content: "Success",
+            is_error: false,
+            contentBlocks: [
+              {
+                type: "image",
+                source: {
+                  type: "base64",
+                  media_type: "image/png",
+                  data: "iVBOR",
+                },
+              },
+            ],
+          },
+        ],
+      },
+    ];
+    await provider.sendMessage(messages);
+
+    const sent = lastStreamParams!.messages as Array<{
+      role: string;
+      content: Array<{
+        type: string;
+        tool_use_id?: string;
+        is_error?: boolean;
+        content?: unknown;
+      }>;
+    }>;
+
+    const toolResult = sent[2].content.find(
+      (b) => b.type === "tool_result" && b.tool_use_id === "tu_img3",
+    )!;
+    expect(toolResult.is_error).toBe(false);
+
+    // Non-error: images should be preserved in the content array
+    const parts = toolResult.content as Array<{ type: string }>;
+    expect(Array.isArray(parts)).toBe(true);
+    expect(parts.some((p) => p.type === "image")).toBe(true);
+  });
 });
 
 // ---------------------------------------------------------------------------

package/src/__tests__/app-builder-tool-scripts.test.ts

@@ -63,7 +63,21 @@ function makeContext(overrides: Partial<ToolContext> = {}): ToolContext {
 
 const mockStore = makeMockStore();
 
-mock.module("../memory/app-store.js", () => mockStore);
+mock.module("../memory/app-store.js", () => ({
+  ...mockStore,
+  getAppsDir: () => "/tmp/test-apps",
+  isMultifileApp: (app: AppDefinition) => app.formatVersion === 2,
+}));
+
+// Mock compileApp for multifile scaffold path
+mock.module("../bundler/app-compiler.js", () => ({
+  compileApp: async () => ({
+    ok: true,
+    errors: [],
+    warnings: [],
+    durationMs: 0,
+  }),
+}));
 
 // ---------------------------------------------------------------------------
 // Import skill scripts (after mocking)

package/src/__tests__/approval-cascade.test.ts

@@ -76,7 +76,7 @@ mock.module("../config/loader.js", () => ({
       summaryModel: "mock-model",
       maxSummaryTokens: 512,
     },
-    rateLimit: { maxRequestsPerMinute: 0, maxTokensPerSession: 0 },
+    rateLimit: { maxRequestsPerMinute: 0 },
     timeouts: { permissionTimeoutSec: 300 },
     skills: { entries: {}, allowBundled: true },
     permissions: { mode: "workspace" },
@@ -166,7 +166,7 @@ mock.module("../memory/retriever.js", () => ({
     injectedTokens: 0,
     latencyMs: 0,
   }),
-  stripMemoryRecallMessages: (msgs: Message[]) => msgs,
+  injectMemoryRecallAsUserBlock: (msgs: Message[]) => msgs,
 }));
 
 mock.module("../context/window-manager.js", () => ({

package/src/__tests__/approval-routes-http.test.ts

@@ -42,9 +42,8 @@ mock.module("../config/loader.js", () => ({
     model: "test",
     provider: "test",
     memory: { enabled: false },
-    rateLimit: { maxRequestsPerMinute: 0, maxTokensPerSession: 0 },
+    rateLimit: { maxRequestsPerMinute: 0 },
     secretDetection: { enabled: false },
-    sandbox: { enabled: false },
     contextWindow: { maxInputTokens: 200000 },
     services: {
       inference: {
@@ -55,9 +54,9 @@ mock.module("../config/loader.js", () => ({
       "image-generation": {
         mode: "your-own",
         provider: "gemini",
-        model: "gemini-2.5-flash-image",
+        model: "gemini-3.1-flash-image-preview",
       },
-      "web-search": { mode: "your-own", provider: "anthropic-native" },
+      "web-search": { mode: "your-own", provider: "inference-provider-native" },
     },
   }),
 }));

package/src/__tests__/asset-materialize-tool.test.ts

@@ -34,7 +34,7 @@ mock.module("../config/loader.js", () => ({
     model: "test",
     provider: "test",
     memory: { enabled: false },
-    rateLimit: { maxRequestsPerMinute: 0, maxTokensPerSession: 0 },
+    rateLimit: { maxRequestsPerMinute: 0 },
   }),
 }));
 
@@ -263,7 +263,7 @@ describe("AssetMaterializeTool materialization", () => {
 describe("AssetMaterializeTool size limit", () => {
   beforeEach(resetTables);
 
-  test("rejects attachment exceeding 50MB limit", async () => {
+  test("rejects attachment exceeding 100MB limit", async () => {
     // Simulate a large attachment by inserting directly into the DB
     // with a sizeBytes value over the limit
     const db = getDb();
@@ -271,7 +271,7 @@ describe("AssetMaterializeTool size limit", () => {
     db.run(
       `INSERT INTO attachments (id, original_filename, mime_type, size_bytes, kind, data_base64, created_at)
        VALUES ('${fakeId}', 'huge.bin', 'application/octet-stream', ${
-         51 * 1024 * 1024
+         101 * 1024 * 1024
        }, 'document', 'AAAA', ${Date.now()})`,
     );
 
@@ -314,8 +314,8 @@ describe("AssetMaterializeTool metadata", () => {
     ).toHaveProperty("destination_path");
   });
 
-  test("tool has MEDIUM risk level", () => {
-    expect(assetMaterializeTool.defaultRiskLevel).toBe(RiskLevel.Medium);
+  test("tool has LOW risk level", () => {
+    expect(assetMaterializeTool.defaultRiskLevel).toBe(RiskLevel.Low);
   });
 
   test("tool category is assets", () => {

package/src/__tests__/asset-search-tool.test.ts

@@ -33,7 +33,7 @@ mock.module("../config/loader.js", () => ({
     model: "test",
     provider: "test",
     memory: { enabled: false },
-    rateLimit: { maxRequestsPerMinute: 0, maxTokensPerSession: 0 },
+    rateLimit: { maxRequestsPerMinute: 0 },
   }),
 }));