privateer-agent 0.10.0 → 0.11.0

package/README.md

@@ -73,6 +73,7 @@ What Privateer adds is a *moat* of Pi extensions layered on top:
 | `privateer-account` | `/signin` billed inference against a Privateer account (device flow) |
 | `privateer-posture`, `privateer-tools` | live attestation shield + Privateer tool pack |
 | `rpiv-web-tools` | private-by-default web search (self-hosted SearXNG, no WebView) |
+| `rpiv-ask-user-question` | `ask_user_question` — a structured questionnaire the agent puts to you instead of guessing |
 | `pi-mcp-adapter`, `pi-subagents` | MCP servers · bounded parallel sub-agents |
 
 They're ordinary Pi extensions — inspect them, replace them, or build your own alongside.
@@ -509,6 +510,9 @@ drop your own into `~/.privateer/agent/extensions/` and it loads the same way, g
   [Workflows](#workflows).
 - **Web tools** (`rpiv-web-tools`) — private-by-default web search/fetch with pluggable backends
   (self-hosted SearXNG for fully private search).
+- **Ask user question** (`rpiv-ask-user-question`) — when a request is underspecified the agent
+  raises a structured questionnaire (typed options, multi-select, markdown previews, or type your
+  own answer) instead of guessing. Ungated by design — it only asks you something.
 
 ## Command reference
 

package/bin/privateer-launch.mjs

@@ -162,7 +162,8 @@ else {
     "privateer-brand", "privateer-context", "privateer-gate", "privateer-account",
     "privateer-models", "privateer-posture", "privateer-tools", "privateer-privacy",
     "privateer-connect",
-    "pi-privacy", "pi-web-access", "rpiv-web-tools", "pi-mcp-adapter", "pi-hypa", "pi-subagents",
+    "pi-privacy", "pi-web-access", "rpiv-web-tools", "rpiv-ask-user-question",
+    "pi-mcp-adapter", "pi-hypa", "pi-subagents",
   ];
   for (const name of MANAGED) fs.rmSync(path.join(EXT_DIR, `${name}.ts`), { force: true });
 
@@ -189,6 +190,7 @@ else {
   shim("privateer-privacy", ext("privateer-privacy.ts"));   // pi-privacy + account tier resolver
   shim("privateer-connect", ext("privateer-connect.ts"));   // /connect — MCP connector manager
   shim("rpiv-web-tools", dep("@juicesharp/rpiv-web-tools", "index.ts")); // private web tools
+  shim("rpiv-ask-user-question", dep("@juicesharp/rpiv-ask-user-question", "index.ts")); // ask_user_question
   shim("pi-mcp-adapter", dep("pi-mcp-adapter", "index.ts"));
   shim("pi-hypa", dep("@hypabolic/pi-hypa", "extensions", "index.ts"));
   shim("pi-subagents", dep("pi-subagents", "src", "extension", "index.ts"));

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "privateer-agent",
-  "version": "0.10.0",
+  "version": "0.11.0",
   "description": "Privateer — a provider-agnostic, safe-by-default terminal coding agent with TEE/Tinfoil attestation, rebuilt on the Pi toolkit. Bring your own model across 20 providers.",
   "type": "module",
   "license": "MIT",
@@ -63,6 +63,7 @@
     "@earendil-works/pi-coding-agent": "0.80.3",
     "@earendil-works/pi-tui": "^0.80.3",
     "@hypabolic/pi-hypa": "^0.1.6",
+    "@juicesharp/rpiv-ask-user-question": "^2.2.0",
     "@juicesharp/rpiv-web-tools": "^1.20.0",
     "@noble/ciphers": "^2.1.1",
     "@noble/curves": "^1.9.7",

package/src/cli/chat.ts

@@ -157,14 +157,16 @@ async function main() {
       console.log(`\n${DIM}⟿ [app] ${text}${RESET}`);
       void (async () => { if (!(await runCommand(text, true))) await runTurn(text, true, false); })();
     },
-    // On (re)attach, resync the transcript, push live context (model + version) so
-    // the app's banner shows what this terminal runs, AND advertise the available
-    // commands so the composer can autocomplete them (incl. extension commands). The
-    // model catalog isn't pushed — /model relays it on demand as a selection prompt.
-    // NON-PII: no cwd — see RelayClient.sendContext.
+    // On (re)attach, resync the transcript, push live context (model + cwd +
+    // version) so the app's banner shows what this terminal runs, AND advertise the
+    // available commands so the composer can autocomplete them (incl. extension
+    // commands). The model catalog isn't pushed — /model relays it on demand as a
+    // selection prompt. `cwd` is home-collapsed on the way out (see sendContext), so
+    // the driver learns which folder they're driving without the OS username
+    // crossing the relay.
     onControllerAttached: () => {
       relay?.sendSnapshot([]);
-      relay?.sendContext({ model: currentSpec, version: agentVersion() });
+      relay?.sendContext({ model: currentSpec, cwd, version: agentVersion() });
       relay?.sendCommands(availableCommands());
     },
     onStatus: (t) => console.log(`\n${DIM}⟿ ${t}${RESET}`),
@@ -602,7 +604,7 @@ async function main() {
       currentSpec = sp;
       const m = `model → ${sp}`;
       console.log(`${DIM}${m}${RESET}`);
-      relay?.sendContext({ model: currentSpec, version: agentVersion() }); // banner follows the switch
+      relay?.sendContext({ model: currentSpec, cwd, version: agentVersion() }); // banner follows the switch
       if (remote) relay?.sendNotice(m);
     } catch (e) {
       const m = `Couldn't switch model: ${(e as Error).message}`;

package/src/permissions/classify.ts

@@ -141,8 +141,17 @@ function unknownTarget(toolName: string, kind: "write" | "edit"): PermissionRequ
 // machine: no gate regardless of arguments. Tunable — the conservative default for
 // anything NOT listed here is to ask (see below). TODO(verify) against Pi's full
 // builtin tool catalog as it's enumerated in Phase 5.
+// `ask_user_question` (rpiv-ask-user-question, shimmed by the launcher) is here on
+// purpose: it is a QUESTION PUT TO THE USER — it renders a dialog and returns what the
+// human picked. It touches nothing, sends nothing, and the human is already in the loop
+// by construction. Gating it would fall through to the unknown-tool branch below, which
+// classifies as bash-kind: a pointless "Run ask_user_question" prompt in default mode,
+// and an outright DENY in plan/readonly — the very posture where a model most needs to
+// ask instead of guess. Headless surfaces need no guard either: the tool self-checks
+// ctx.hasUI and returns an error result when there's no one to ask.
 const NON_GATED = new Set([
   "todo", "todowrite", "todo_write", "todoread", "think", "plan_note",
+  "ask_user_question",
 ]);
 
 // Read-ish builtins: gated ONLY when the target resolves outside scope.

package/src/providers/account.ts

@@ -114,10 +114,37 @@ export function loadCachedCatalogIds(): string[] {
   }
 }
 
+// Whether the account channel can actually SERVE a catalog model right now.
+//
+// `phala/*` is sealed-only: it runs through the sealed blind relay and nowhere else.
+// The server's cleartext `/api/agent/v1` has no Phala route and rejects the id
+// outright (verified live 2026-07-31: 400 "phala/… is not a valid model ID"), because
+// Phala models are the Sealed tier by design — the server is not meant to be able to
+// read them. But `/api/models` advertises them to every client regardless of whether
+// that client can reach the sealed path, so they were pickable and then failed on the
+// first prompt. Offering a model we know cannot answer is worse than a shorter list.
+//
+// The condition is the SHIM, not the flag. Sealed mode being enabled only means we
+// intend to seal; `phala/*` is unservable until the loopback shim is actually
+// listening, because that is what its per-model baseUrl points at (see modelEntry).
+// With the flag now defaulting on, "enabled but the shim failed to bind" is a state a
+// user can really land in, and it must not re-offer models that would 400.
+//
+// `tinfoil/*` is deliberately NOT filtered: the cleartext path serves it fine (sealed
+// mode only upgrades the badge from unconfirmed to verified), so it stays either way.
+export function isServableAccountModel(id: string): boolean {
+  if (!id.startsWith("phala/")) return true;
+  return sealedEnabled() && sealedShimBase() !== null;
+}
+
 // The ids to register synchronously at load. DEFAULT_MODELS FIRST and always: the account
 // default has to be index 0 both because it must always resolve and because Pi clones the
 // provider's first/default model when it synthesizes a custom model id
 // (model-resolver.js buildFallbackModel).
+//
+// Returns the server's list as cached, unfiltered — accountProviderConfig decides what
+// is servable at each registration, so a model dropped now (shim not up yet) can be
+// re-offered by a later re-registration without the cache being rewritten.
 export function seedCatalogIds(): string[] {
   const ids = [...DEFAULT_MODELS];
   const seen = new Set(ids);
@@ -202,7 +229,9 @@ export async function fetchAccountCatalog(): Promise<AccountModelInfo[]> {
         .map((m) => (m.modelId ? { id: m.modelId, tier: normalizeTier(m.privacy?.tier, m.modelId) } : null))
         .filter((x): x is AccountModelInfo => !!x);
       // Cache only a real LIVE listing — never the fallback, which would freeze the six
-      // seed ids on disk and read back as though it were the catalog.
+      // seed ids on disk and read back as though it were the catalog. Both the cache and
+      // the returned list are the server's UNFILTERED offer; servability is decided at
+      // registration (accountProviderConfig), which re-evaluates it every time.
       if (parsed.length) saveCachedCatalogIds(parsed.map((p) => p.id));
       infos = parsed.length ? parsed : fallback();
     }
@@ -402,14 +431,15 @@ export async function accountPosture(modelId: string): Promise<AccountPosture> {
     const att = await attestSealed(sealedProvider);
     return att.ok ? { tier: "tee-verified" } : { tier: "tee-unverified", error: att.error };
   }
-  // Honest labelling for the non-NEAR enclaves without sealed mode. Tinfoil and Phala
-  // publish real attestations, but the server proxies the inference in cleartext, so
-  // from here we cannot bind a quote to the connection actually carrying our tokens —
-  // only the account's word that it did. That's `tee-unverified` (yellow "confidential
-  // compute, unconfirmed"), never the green tee-verified we reserve for a quote we
-  // checked ourselves. Turn on sealed mode (PRIVATEER_SEALED=1) for the verified
-  // shield, or set TINFOIL_API_KEY and run `tinfoil/*` direct (pi-privacy attests
-  // client-side over the TLS binding).
+  // Honest labelling for the non-NEAR enclaves when we are NOT sealing — sealed mode
+  // explicitly disabled (PRIVATEER_SEALED=0), or on but the shim never came up. Tinfoil
+  // and Phala publish real attestations, but the server proxies the inference in
+  // cleartext, so from here we cannot bind a quote to the connection actually carrying
+  // our tokens — only the account's word that it did. That's `tee-unverified` (yellow
+  // "confidential compute, unconfirmed"), never the green tee-verified we reserve for a
+  // quote we checked ourselves. Re-enable sealed mode for the verified shield, or set
+  // TINFOIL_API_KEY and run `tinfoil/*` direct (pi-privacy attests client-side over the
+  // TLS binding).
   if (!modelId.startsWith("near/")) {
     return { tier: "tee-unverified" };
   }
@@ -429,11 +459,13 @@ export async function accountPosture(modelId: string): Promise<AccountPosture> {
   }
 }
 
-// A model entry, with a per-model baseUrl override once the EHBP shim is listening:
-// `tinfoil/*` then route through the loopback shim (which seals to the blind relay)
-// instead of the cleartext `/api/agent/v1` proxy. Everything else keeps the provider
-// baseUrl. Until the shim is up (or when sealed mode is off) sealed models fall back to
-// the cleartext path — and the badge stays honestly `tee-unverified` (see accountPosture).
+// A model entry, with a per-model baseUrl override once the sealed shim is listening:
+// `tinfoil/*` and `phala/*` then route through the loopback shim (which seals to the
+// blind relay) instead of the cleartext `/api/agent/v1` proxy. Everything else keeps the
+// provider baseUrl. Until the shim is up (or with sealed mode disabled) `tinfoil/*` falls
+// back to the cleartext path and the badge stays honestly `tee-unverified` (see
+// accountPosture); `phala/*` has no cleartext path at all and is not registered in that
+// state (see isServableAccountModel).
 function modelEntry(id: string) {
   const base = seedModel(id);
   const provider = sealedEnabled() ? sealedProviderFor(id) : null;
@@ -448,7 +480,13 @@ export function accountProviderConfig(ids: string[]): Record<string, unknown> {
     baseUrl: `${serverBaseUrl()}/api/agent/v1`,
     api: "openai-completions",
     oauth: privateerOAuthProvider,
-    models: ids.map(modelEntry),
+    // Filter HERE rather than at the catalog, so callers keep passing the server's
+    // full list and every registration re-evaluates servability against the CURRENT
+    // shim state. That is what lets the post-shim re-registration in makeAccountProvider
+    // put `phala/*` back: had the ids been filtered upstream, the sealed-only models
+    // would have been dropped from `lastIds` before the shim ever finished starting and
+    // nothing would have brought them back.
+    models: ids.filter(isServableAccountModel).map(modelEntry),
   };
 }
 

package/src/providers/phala/aci-verifier/VENDORED.md

@@ -21,3 +21,19 @@ Everything else is byte-for-byte upstream. The crypto runs on `globalThis.crypto
 (Node ≥ 22) these are all native — **no polyfills needed** (unlike the treeview RN app,
 which bridges them via `react-native-quick-crypto`). Re-pull from upstream to update;
 re-apply only the `.js`-extension strip.
+
+## What lives OUTSIDE this directory (and why)
+`../reportBinding.ts` — `verifyAciReportBinding`, the algorithm dispatch for §10.1
+checks 2–6. Callers use it instead of importing `verifyReportBinding` from here.
+
+Upstream's verifier is Web-Crypto-only, so it throws `UnsupportedAlgorithmError` on
+an `ecdsa-secp256k1` keyset endorsement — which §4.3 explicitly permits alongside
+ed25519, and which the deployed `inference.phala.com` gateway actually uses. Rather
+than patch this tree (and re-patch it on every re-pull), the dispatch sits outside:
+ed25519 delegates here verbatim, secp256k1 takes a parallel path over `@noble/curves`,
+and any other algorithm still throws. Nothing here changed, so the re-pull recipe
+above stays exactly the `.js`-extension strip.
+
+If upstream ever adds secp256k1 (or a check 7) to `report.ts`, collapse
+`reportBinding.ts` back to a straight re-export — `tests/phalaReportBinding.test.ts`
+pins the behaviour either way.

package/src/providers/phala/reportBinding.ts

@@ -0,0 +1,193 @@
+// Algorithm dispatch for the ACI report-binding checks (§10.1 checks 2–6).
+//
+// The ACI spec (§4.3) allows the keyset endorsement to be signed with EITHER
+// `ed25519` OR `ecdsa-secp256k1` — the former because "every primitive in it is
+// available in the Web Crypto API", the latter for "clients in the EVM/dstack
+// ecosystem". Upstream's reference TS verifier implements only the Web Crypto half:
+// `verifySignature` throws `UnsupportedAlgorithmError` on secp256k1
+// (aci-verifier/crypto.ts), and `verifyReportBinding` propagates that.
+//
+// The deployed gateway (inference.phala.com) signs with `ecdsa-secp256k1`, so the
+// vendored verifier can never attest it — a limit of upstream's CLIENT, not of the
+// spec or the gateway. Verified live 2026-07-31: attestation fetched, endorsement
+// rejected with UnsupportedAlgorithmError.
+//
+// This module owns the dispatch so `aci-verifier/` stays byte-for-byte upstream
+// (see its VENDORED.md — only the `.js`-extension strip diverges, and re-pulls stay
+// mechanical):
+//   ed25519         → delegate to the vendored verifyReportBinding, verbatim
+//   ecdsa-secp256k1 → the same checks 2–6, with check 5 done over @noble/curves
+//   anything else   → still throws (never a silent pass)
+//
+// The secp256k1 path deliberately mirrors report.ts check-for-check, in the same
+// order and with the same check names, so a caller cannot tell which path ran.
+
+import { secp256k1 } from "@noble/curves/secp256k1.js";
+import {
+  verifyReportBinding,
+  computeWorkloadId,
+  computeKeysetDigest,
+  computeReportData,
+  keysetEndorsementPayload,
+  sha256,
+  fromHex,
+  UnsupportedAlgorithmError,
+  type AttestationReport,
+  type Check,
+  type ReportVerification,
+  type ReportBindingOptions,
+} from "./aci-verifier/index.ts";
+
+const ED25519 = "ed25519";
+const SECP256K1 = "ecdsa-secp256k1";
+
+/**
+ * Verify a report's cryptographic bindings for `nonce` (§10.1 checks 2–6),
+ * dispatching on the algorithm the attested identity key declares. Drop-in
+ * replacement for the vendored `verifyReportBinding`: same arguments, same result
+ * shape, same "a failed check is `ok: false`, never thrown" contract.
+ *
+ * Like upstream, this is the crypto-binding half only — compose it with a hardware
+ * quote verifier (phalaSeal.ts `verifyHardwareQuote`) for Level 2.
+ */
+export async function verifyAciReportBinding(
+  report: AttestationReport,
+  nonce: string | null | undefined,
+  options: ReportBindingOptions = {},
+): Promise<ReportVerification> {
+  const algo = report.attestation.workload_keyset.workload_identity.public_key.algo;
+  if (algo === ED25519) return verifyReportBinding(report, nonce, options);
+  if (algo !== SECP256K1) {
+    // Same fail-closed posture as upstream: an algorithm we cannot check is a
+    // refusal, not a pass.
+    throw new UnsupportedAlgorithmError(algo, "keyset endorsement (§4.3)");
+  }
+  return verifySecp256k1ReportBinding(report, nonce, options);
+}
+
+async function verifySecp256k1ReportBinding(
+  report: AttestationReport,
+  nonce: string | null | undefined,
+  options: ReportBindingOptions,
+): Promise<ReportVerification> {
+  const now = options.now ?? Math.floor(Date.now() / 1000);
+  const checks: Check[] = [];
+
+  const keyset = report.attestation.workload_keyset;
+  const identityKey = keyset.workload_identity.public_key;
+
+  // Check 2: workload_id == digest of the identity public key in the report's keyset.
+  const workloadId = await computeWorkloadId(identityKey);
+  pushEqual(checks, "workload_id", report.workload_id, workloadId);
+
+  // Check 3: workload_keyset_digest == digest of the report's keyset.
+  const workloadKeysetDigest = await computeKeysetDigest(keyset);
+  pushEqual(checks, "workload_keyset_digest", report.workload_keyset_digest, workloadKeysetDigest);
+
+  // Check 4 (binding half): report_data == the §4.4 statement digest for this nonce.
+  // The hardware-evidence-binds-report_data half is verifyHardwareQuote's job.
+  const expectedReportData = await computeReportData(workloadId, workloadKeysetDigest, nonce);
+  pushEqual(checks, "report_data", report.attestation.report_data, expectedReportData);
+
+  // Check 5: keyset endorsement verifies under the identity key, algo matching.
+  const endorsement = report.attestation.keyset_endorsement;
+  if (endorsement.algo !== identityKey.algo) {
+    checks.push({
+      name: "keyset_endorsement",
+      ok: false,
+      detail: `endorsement.algo "${endorsement.algo}" != identity key algo "${identityKey.algo}"`,
+    });
+  } else {
+    const ok = await verifySecp256k1(
+      identityKey.public_key,
+      endorsement.value,
+      keysetEndorsementPayload(workloadKeysetDigest),
+    );
+    checks.push({
+      name: "keyset_endorsement",
+      ok,
+      ...(ok ? {} : { detail: "endorsement signature failed under identity key" }),
+    });
+  }
+
+  // Check 6: freshness. Nonce binding is check 4; here bound the epoch and, when
+  // the profile trusts it, the declared validity window.
+  const notAfter = keyset.keyset_epoch.not_after;
+  const epochOk = now < notAfter;
+  checks.push({
+    name: "keyset_epoch.not_after",
+    ok: epochOk,
+    ...(epochOk ? {} : { detail: `now ${now} >= not_after ${notAfter}` }),
+  });
+  if (options.trustPlatformClock) {
+    const freshness = report.attestation.freshness;
+    const fetchedAt = freshness?.fetched_at;
+    const staleAfter = freshness?.stale_after;
+    const windowOk =
+      typeof fetchedAt === "number" &&
+      typeof staleAfter === "number" &&
+      fetchedAt <= now &&
+      now < staleAfter;
+    checks.push({
+      name: "freshness_window",
+      ok: windowOk,
+      ...(windowOk ? {} : { detail: `now ${now} outside [${fetchedAt}, ${staleAfter})` }),
+    });
+  }
+
+  return { ok: checks.every((c) => c.ok), checks, workloadId, workloadKeysetDigest };
+}
+
+/**
+ * §4.3 secp256k1 endorsement: a 64-byte `r || s` signature over
+ * `sha256(payload bytes)`. Returns false on malformed input rather than throwing —
+ * a bad signature is a failed check, not an exception.
+ *
+ * NOT the §8.5 *receipt* shape, which is a 65-byte recoverable `r || s || v` and
+ * where the spec says 64-byte signatures MUST be rejected. Different shapes; easy
+ * to conflate if this ever grows a receipt path.
+ */
+async function verifySecp256k1(
+  publicKeyHex: string,
+  signatureHex: string,
+  payload: Uint8Array,
+): Promise<boolean> {
+  try {
+    const sig = fromHex(signatureHex);
+    if (sig.length !== 64) return false; // r||s only; DER / recoverable forms are not §4.3
+    const msgHash = await sha256(payload);
+    return secp256k1.verify(sig, msgHash, publicKey(publicKeyHex), {
+      prehash: false, // we hand it the sha256 digest, per §4.3
+      // Accept high-s as well as low-s. ECDSA malleability is meaningless for a
+      // signature over a FIXED payload — an attacker who can flip s already has a
+      // valid endorsement and still cannot sign a different keyset digest. Leaving
+      // the default on would reject ~half of otherwise-valid endorsements from any
+      // signer that doesn't normalize, as an intermittent attestation failure.
+      lowS: false,
+    });
+  } catch {
+    return false;
+  }
+}
+
+/**
+ * Identity key bytes. §7.1 pins secp256k1 public keys as 65-byte uncompressed SEC1
+ * and requires that "the 64-byte uncompressed form without the `0x04` prefix MUST be
+ * accepted and treated as the same key" — so restore the prefix when it's absent.
+ * The live gateway sends the 65-byte form; do NOT prefix that one again.
+ */
+function publicKey(hex: string): Uint8Array {
+  const raw = fromHex(hex);
+  if (raw.length === 64) {
+    const sec1 = new Uint8Array(65);
+    sec1[0] = 0x04;
+    sec1.set(raw, 1);
+    return sec1;
+  }
+  return raw;
+}
+
+function pushEqual(checks: Check[], name: string, actual: string, expected: string): void {
+  const ok = actual === expected;
+  checks.push({ name, ok, ...(ok ? {} : { detail: `report ${actual} != recomputed ${expected}` }) });
+}

package/src/providers/phalaSeal.ts

@@ -13,7 +13,7 @@
 // no polyfills, unlike the RN app.
 //
 // Two-layer attestation, fail-secure:
-//   (1) verifyReportBinding — the report's crypto binding (keyset digest,
+//   (1) verifyAciReportBinding — the report's crypto binding (keyset digest,
 //       report_data == statement(nonce), endorsement sig). Self-attesting alone.
 //   (2) verifyHardwareQuote — the hardware root: @phala/dcap-qvl verifies the TDX quote
 //       against Intel collateral and binds the quote's report_data to (1)'s statement
@@ -22,7 +22,6 @@
 
 import type { Report } from "@phala/dcap-qvl";
 import {
-  verifyReportBinding,
   openE2eeChannel,
   toHex,
   fromHex,
@@ -30,6 +29,11 @@ import {
   type ReportVerification,
   type E2eeChannel,
 } from "./phala/aci-verifier/index.ts";
+// Not the vendored verifyReportBinding directly: the deployed gateway signs its
+// keyset endorsement with ecdsa-secp256k1, which upstream's Web-Crypto-only verifier
+// refuses. This wrapper delegates ed25519 to it unchanged and adds the secp256k1 arm
+// the spec allows (§4.3), leaving aci-verifier/ pristine for re-pulls.
+import { verifyAciReportBinding } from "./phala/reportBinding.ts";
 import { serverBaseUrl } from "../auth/privateer.ts";
 
 const DEFAULT_ACCEPTABLE_TCB = ["UpToDate"];
@@ -94,7 +98,7 @@ async function establishAttestation(): Promise<VerifiedAttestation> {
   if (!res.ok) throw new Error(`phala attestation HTTP ${res.status}`);
   const report = (await res.json()) as AttestationReport;
 
-  const verification = await verifyReportBinding(report, nonce);
+  const verification = await verifyAciReportBinding(report, nonce);
   if (!verification.ok) {
     const failed = verification.checks.filter((c) => !c.ok).map((c) => c.name).join(", ");
     throw new Error(`phala attestation binding failed: ${failed}`);

package/src/providers/sealedShim.ts

@@ -40,13 +40,22 @@ import { iterateSSE } from "./phala/sse.ts";
 // (unsealed) path, not sealed. See docs/tee-verified-tinfoil-ehbp.md §12.
 export type SealedProvider = "tinfoil" | "phala";
 
-// Sealed mode is OFF until verified end-to-end against a live relay (a real EHBP
-// round-trip needs the deployed relay + TINFOIL_API_KEY; see the live checklist in
-// docs/tee-privateer-tinfoil-ehbp.md). Off = the current plaintext path + honest
-// yellow badge, untouched. Flip with PRIVATEER_SEALED=1.
+// Sealed mode is ON by default as of 2026-07-31, when the live checklist in
+// docs/tee-verified-tinfoil-ehbp.md passed end to end against the deployed relay:
+// both enclaves attest client-side (Tinfoil HPKE-key match; Phala report binding +
+// TDX quote), a sealed turn round-trips and streams incrementally, a bogus enclave is
+// refused rather than silently greened, and the server bills the turn.
+//
+// What it buys: the prompt is sealed to the enclave the client itself attested, so the
+// badge is a quote WE checked rather than the account's word — green instead of
+// "Trusted Execution (unconfirmed)".
+//
+// PRIVATEER_SEALED=0 (or =false) drops back to the cleartext `/api/agent/v1` path and
+// the honest yellow badge. Note that is a real downgrade for `phala/*`, which is
+// sealed-only and simply disappears from the catalog (see isServableAccountModel).
 export function sealedEnabled(): boolean {
   const v = process.env.PRIVATEER_SEALED;
-  return v === "1" || v === "true";
+  return !(v === "0" || v === "false");
 }
 
 // The sealed provider a model id routes through, or null if it isn't a sealed
@@ -151,7 +160,12 @@ export function buildForward(
     // Not JSON — forward unchanged (X-Sealed-Model stays "unknown"; relay logs it).
   }
   const headers: Record<string, string> = {
-    "Content-Type": "application/json",
+    // MUST carry the charset. EHBP seals the body but headers travel in cleartext
+    // (tinfoil/dist/encrypted-body-fetch.js: "EHBP only seals the body"), so this
+    // Content-Type is what the enclave's router actually validates — and it rejects a
+    // bare `application/json` with "Unsupported Media Type: Only 'application/json' is
+    // allowed" (verified live 2026-07-31: bare → 400, any `charset=` variant → 200).
+    "Content-Type": "application/json; charset=utf-8",
     "X-Sealed-Model": sealedModel,
   };
   if (authHeader) headers.Authorization = authHeader;
@@ -165,6 +179,7 @@ const LOOPBACK = new Set(["127.0.0.1", "::1", "::ffff:127.0.0.1"]);
 
 let shimBase: string | null = null;
 let shimStarting: Promise<string> | null = null;
+let shimServer: http.Server | null = null;
 
 // The shim's base URL once listening, else null. account.ts reads this to decide
 // whether a sealed model can point its baseUrl at the shim yet.
@@ -179,6 +194,19 @@ export function ensureSealedShim(): Promise<string> {
   return shimStarting;
 }
 
+// Close the shim and forget it, so a later ensureSealedShim() starts a fresh one.
+// The listener is `unref`'d and never blocks exit, so this is not needed for
+// shutdown — it exists so a caller that stops sealing (or a test) can drop the
+// socket deterministically rather than leaving a port open for the process lifetime.
+export function stopSealedShim(): Promise<void> {
+  const server = shimServer;
+  shimServer = null;
+  shimBase = null;
+  shimStarting = null;
+  if (!server) return Promise.resolve();
+  return new Promise((resolve) => server.close(() => resolve()));
+}
+
 function startShim(): Promise<string> {
   return new Promise((resolve, reject) => {
     const server = http.createServer((req, res) => {
@@ -192,6 +220,7 @@ function startShim(): Promise<string> {
     server.listen(0, "127.0.0.1", () => {
       const addr = server.address();
       if (addr && typeof addr === "object") {
+        shimServer = server;
         shimBase = `http://127.0.0.1:${addr.port}`;
         resolve(shimBase);
       } else {

package/src/remote/extensionsControl.ts

@@ -61,6 +61,8 @@ const RESERVED = new Set([
   "pi-web-access",
   "rpiv-web-tools",
   "@juicesharp/rpiv-web-tools",
+  "rpiv-ask-user-question",
+  "@juicesharp/rpiv-ask-user-question",
   "pi-mcp-adapter",
   "pi-hypa",
   "@hypabolic/pi-hypa",

package/src/remote/relayClient.ts

@@ -996,13 +996,14 @@ export class RelayClient {
   // stance (the server/controller learns as little as possible about the machine).
   // Empty/absent fields are omitted so the app renders less rather than blank.
   //
-  // `cwd` is the one scoped exception, and ONLY a harbor-spawned live session passes
-  // it (see liveTaskSession): the driver chose that directory in the spawn form — or,
-  // having left it blank, needs to see which one the harbor picked — because it is
-  // where everything that session reads, writes and `@`-mentions lives, and unlike an
-  // interactive terminal there is no human sitting in it to already know. It is
-  // home-collapsed (`~/…`) on the way out, so the banner reads like the CLI's own and
-  // the OS username still never crosses the relay.
+  // `cwd` is the one scoped exception, sent by BOTH session kinds: it is where
+  // everything the agent reads, writes and `@`-mentions lives, so a driver who can't
+  // see it is guessing at the blast radius of every prompt they send. (It used to be
+  // harbor-spawned sessions only — on the theory that a human sits in an interactive
+  // terminal and already knows the folder. They don't when they're driving it from a
+  // phone, which is the entire point of this transport.) It is home-collapsed (`~/…`)
+  // on the way out, so the banner reads like the CLI's own and the OS username still
+  // never crosses the relay.
   sendContext(ctx: { model?: string; version?: string; cwd?: string; terminalPub?: string }): void {
     const frame: Record<string, unknown> = { type: "context" };
     if (typeof ctx.model === "string" && ctx.model) frame.model = ctx.model;