@askexenow/exe-os 0.9.374 → 0.9.377

package/deploy/compose/.env.customer.example

@@ -149,7 +149,22 @@ WIKI_IMAGE_TAG=update.askexe.com/askexe/exe-wiki:v0.9.28@sha256:61856a4c6b97ce62
 # only thing holding production together was a host-local compose override.
 # exe-wiki-schema-guard blocks the boot if you get this wrong.
 WIKI_DB_SCHEMA=public
-WIKI_VECTOR_DB=exeOsMcp
+# Bugs bed3cb4a / c604df37 — see deploy/compose/docker-compose.yml's exe-wiki
+# environment block for the full rationale. pgvector reuses this same
+# exe-db instance; native runs in-process (no API key, no exe-os MCP daemon).
+WIKI_VECTOR_DB=pgvector
+# bug bed3cb4a / corrected 2026-08-31 (founder direction): wiki's RAG/chat
+# uses GLM via Z.ai directly (exe-wiki PR #78's real, verified `zai`
+# provider) — not Anthropic through exe-gateway. Supply ZAI_API_KEY to match.
+WIKI_LLM_PROVIDER=zai
+ZAI_MODEL_PREF=glm-4.6
+ZAI_BASE_PATH=https://api.z.ai/api/coding/paas/v4
+# exe-gateway's /v1/messages authenticates via an exe_sk_* billing API key
+# (exe-gateway src/api-keys.ts), provisioned per-customer through
+# dashboard.askexe.com — it cannot be generated here. Chat/RAG will fail
+# ("No Anthropic API key was set") until this is set.
+# SET_MANUALLY
+WIKI_ANTHROPIC_API_KEY=CHANGEME_WIKI_ANTHROPIC_API_KEY
 WIKI_AUTH_TOKEN=CHANGEME_WIKI_AUTH_TOKEN
 WIKI_JWT_SECRET=CHANGEME_WIKI_JWT_SECRET
 WIKI_SIG_KEY=CHANGEME_WIKI_SIG_KEY

package/deploy/compose/.env.example

@@ -179,7 +179,22 @@ WIKI_IMAGE_TAG=ghcr.io/askexe/exe-wiki:v0.9.28@sha256:61856a4c6b97ce62c62ecdc3a3
 # only thing holding production together was a host-local compose override.
 # exe-wiki-schema-guard blocks the boot if you get this wrong.
 WIKI_DB_SCHEMA=public
-WIKI_VECTOR_DB=exeOsMcp
+# Bugs bed3cb4a / c604df37 — see deploy/compose/docker-compose.yml's exe-wiki
+# environment block for the full rationale. pgvector reuses this same
+# exe-db instance; native runs in-process (no API key, no exe-os MCP daemon).
+WIKI_VECTOR_DB=pgvector
+# bug bed3cb4a / corrected 2026-08-31 (founder direction): wiki's RAG/chat
+# uses GLM via Z.ai directly (exe-wiki PR #78's real, verified `zai`
+# provider) — not Anthropic through exe-gateway. Supply ZAI_API_KEY to match.
+WIKI_LLM_PROVIDER=zai
+ZAI_MODEL_PREF=glm-4.6
+ZAI_BASE_PATH=https://api.z.ai/api/coding/paas/v4
+# exe-gateway's /v1/messages authenticates via an exe_sk_* billing API key
+# (exe-gateway src/api-keys.ts), provisioned per-customer through
+# dashboard.askexe.com — it cannot be generated here. Chat/RAG will fail
+# ("No Anthropic API key was set") until this is set.
+# SET_MANUALLY
+WIKI_ANTHROPIC_API_KEY=CHANGEME_WIKI_ANTHROPIC_API_KEY
 WIKI_AUTH_TOKEN=CHANGEME_WIKI_AUTH_TOKEN
 EXE_WIKI_ADMIN_TOKEN=CHANGEME_EXE_WIKI_ADMIN_TOKEN
 WIKI_JWT_SECRET=CHANGEME_WIKI_JWT_SECRET

package/deploy/compose/docker-compose.yml

@@ -467,6 +467,13 @@ services:
       STORAGE_TYPE: local
       STORAGE_LOCAL_PATH: /app/.local-storage
       BRANDING_CONFIG_PATH: /app/branding.json
+      # Bug 2355a199 / exe-crm PR #125: exe-crm sits behind two hops of reverse
+      # proxy (cloudflared -> exe-sso-edge -> exe-crm), so the raw peer address
+      # Node sees is exe-sso-edge, not the real client. Without telling the app
+      # how many trusted hops to peel off X-Forwarded-For, rate limiting keys on
+      # the wrong address (the edge, shared by every request) instead of the
+      # actual client.
+      EXE_TRUSTED_PROXY_HOPS: "2"
     ports:
       - "127.0.0.1:${CRM_HOST_PORT:-3000}:3000"
     volumes:
@@ -684,25 +691,78 @@ services:
       JWT_SECRET: ${WIKI_JWT_SECRET:?WIKI_JWT_SECRET is required}
       SIG_KEY: ${WIKI_SIG_KEY:?WIKI_SIG_KEY is required}
       SIG_SALT: ${WIKI_SIG_SALT:?WIKI_SIG_SALT is required}
-      # Embeddings (bug 49221421): in the current wiki build the ONLY functional
-      # embedding path is the exeOsMcp vector provider, which spawns the exe-os
-      # MCP daemon over stdio and owns vectorization. The pgvector/postgres path
-      # relies on an inert embedder shim and silently produces NO vectors, so it
-      # must NOT be the default. We default the wiki to exeOsMcp + native and
-      # wire the stdio spawn command below so embeddings actually work. If an
-      # operator overrides WIKI_VECTOR_DB to a non-mcp engine while leaving
-      # EMBEDDING_ENGINE=native and no MCP command, the wiki now FAILS LOUD at
-      # boot (see server/utils/boot/productionEnv.js) instead of silent no-op.
-      VECTOR_DB: ${WIKI_VECTOR_DB:-exeOsMcp}
+      # Embeddings + vector DB (bugs bed3cb4a, c604df37). This used to default to
+      # exeOsMcp + native, on the assumption that exeOsMcp was the only functional
+      # embedding path. Two things changed that:
+      #   1. exe-wiki PR #78 ("revive the embedding pipeline, unbreak pgvector
+      #      retrieval", merged 2026-08-31) restored the real EMBEDDING_ENGINE
+      #      switch in getEmbeddingEngineSelection() (it had been reduced to an
+      #      unconditional exeOsMcp shim) and fixed pgvector's table-schema
+      #      resolution (server/utils/vectorDbProviders/pgvector). native + pgvector
+      #      is now the wiki's own documented default (docker/.env.example) and a
+      #      genuinely self-contained combo: native runs @xenova/transformers
+      #      in-process — no API key, no exe-os MCP daemon, no separate database.
+      #   2. bug c604df37: the exeOsMcp path was never actually reachable in
+      #      production. server/utils/vectorDbProviders/exeOsMcpClient spawns
+      #      `npx @askexenow/exe-os@<pin> mcp`, but in exe-os `args[0] === "mcp"`
+      #      (src/bin/cli.ts) routes to the Claude Code MCP config-manager CLI
+      #      (src/bin/exe-mcp.ts), not the JSON-RPC stdio server
+      #      (src/mcp/server.ts, exposed only as a package export with no bin
+      #      entry). The handshake never completes and every embed call no-ops.
+      # Default to pgvector so a fresh deploy actually vectorizes documents.
+      # exeOsMcp remains selectable via WIKI_VECTOR_DB for an operator who fixes
+      # the client-side routing bug above first.
+      VECTOR_DB: ${WIKI_VECTOR_DB:-pgvector}
       EMBEDDING_ENGINE: ${WIKI_EMBEDDING_ENGINE:-native}
-      # stdio spawn of the exe-os MCP server. The wiki client only supports
-      # stdio transport today (HTTP to the exe-os service is not wired yet), so
-      # the wiki runs its own pinned exe-os MCP subprocess for embedding.
-      # bug 8d084f7c: PIN the exe-os npm version. An unversioned `npx
-      # @askexenow/exe-os` resolves to whatever "latest" is at boot, so a customer
-      # could silently run a different MCP build than the rest of the stack (and
-      # offline boots fail). WIKI_EXE_OS_NPM_VERSION defaults to the stack's
-      # pinned exe-os npm version and is threaded into the spawn args.
+      # pgvector reuses the SAME exe-db Postgres instance the wiki's own
+      # DATABASE_URL points at — exe-db already runs pgvector/pgvector:pg16 (see
+      # the exe-db image comment above), so `CREATE EXTENSION IF NOT EXISTS
+      # vector` in server/utils/vectorDbProviders/pgvector/index.js succeeds with
+      # no separate database or extra service to provision.
+      #
+      # NOTE this is NOT the same shape as DATABASE_URL above: PGVECTOR_CONNECTION_STRING
+      # is handed straight to the `pg` client, not Prisma, so it does not understand
+      # a `?schema=` query param (Prisma-only syntax) — it is deliberately omitted.
+      # pgvector resolves its own table (default name `exe-wiki_vectors`, see
+      # PGVECTOR_TABLE_NAME) through the connection's default search_path, i.e. the
+      # same `public` schema the wiki's own Prisma tables live in (WIKI_DB_SCHEMA
+      # above). See server/utils/vectorDbProviders/pgvector/SETUP.md for the
+      # provider's own setup notes.
+      PGVECTOR_CONNECTION_STRING: ${WIKI_PGVECTOR_CONNECTION_STRING:-postgres://${POSTGRES_USER:-exe}:${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required}@exe-db:5432/${POSTGRES_DB:-exedb}?sslmode=disable}
+      # LLM provider (bug bed3cb4a, corrected per founder direction 2026-08-31:
+      # wiki's RAG/chat must use GLM, not Anthropic-via-gateway).
+      #
+      # A fresh deploy shipped NO LLM_PROVIDER at all, so AnythingLLM's
+      # getLLMProvider() fell back to the OpenAI provider, which throws "No
+      # OpenAI API key was set" on every chat/RAG request. exe-wiki PR #78 added
+      # a real, working `zai` provider directly (no gateway hop needed — GLM/Z.ai
+      # exposes its own OpenAI-Messages-compatible endpoint that the wiki client
+      # speaks natively), verified end-to-end against a real uploaded PDF
+      # including a negative control (correctly declines to answer an
+      # out-of-corpus question rather than hallucinating). Use that.
+      #
+      # An earlier draft of this config pointed wiki at exe-gateway with
+      # LLM_PROVIDER=anthropic instead, reasoning that the gateway only speaks
+      # the Anthropic Messages protocol. That reasoning is correct AS FAR AS THE
+      # GATEWAY GOES, but it's the wrong fix: it routes around wiki's own
+      # already-built, already-verified GLM integration instead of using it, and
+      # it does not match what the founder explicitly asked for. If exe-wiki
+      # ever needs to go through exe-gateway instead of calling Z.ai directly
+      # (e.g. for centralized billing/rate-limiting), that's a deliberate future
+      # change, not the default.
+      LLM_PROVIDER: ${WIKI_LLM_PROVIDER:-zai}
+      # Z.ai key is an account credential, not a generatable secret — left empty
+      # so the operator fills it in; compose reads it as ${ZAI_API_KEY:-} rather
+      # than failing closed. WARN-first check for this lives in generate-env.ts.
+      ZAI_API_KEY: ${ZAI_API_KEY:-}
+      ZAI_MODEL_PREF: ${ZAI_MODEL_PREF:-glm-4.6}
+      # bug 62ba51e9: default to the Coding Plan path (the entitlement we hold).
+      # ZAI_BASE_PATH is only honoured by a wiki image carrying exe-wiki PR #78;
+      # older images hardcode the PAYG path and will 1113 regardless of this.
+      ZAI_BASE_PATH: ${ZAI_BASE_PATH:-https://api.z.ai/api/coding/paas/v4}
+      # stdio spawn of the exe-os MCP server. Only used if WIKI_VECTOR_DB is
+      # overridden back to exeOsMcp — see bug c604df37 above before doing that;
+      # the spawn args below currently point at the wrong CLI entrypoint.
       EXE_OS_MCP_COMMAND: ${WIKI_EXE_OS_MCP_COMMAND:-npx}
       EXE_OS_MCP_ARGS: ${WIKI_EXE_OS_MCP_ARGS:--y @askexenow/exe-os@${WIKI_EXE_OS_NPM_VERSION:-0.9.324} mcp}
       BRANDING_CONFIG_PATH: /app/branding.json
@@ -1221,6 +1281,8 @@ services:
       - ./sso-edge/default.conf.template:/etc/nginx/exe-templates/default.conf.template:ro
       - ./sso-edge/sso-redirect.conf:/etc/nginx/snippets/sso-redirect.conf:ro
       - ./sso-edge/entrypoint.sh:/docker-entrypoint.d/99-render-sso-edge.sh:ro
+      # Branded shared error pages (packages/exe-error-pages, vendored by its sync.mjs; bug 64324162).
+      - ./sso-edge/error-pages:/usr/share/nginx/html/error-pages:ro
     # nginx:alpine runs /docker-entrypoint.d/*.sh then `nginx -g 'daemon off;'`.
     # Our script renders the template from ${DOMAIN}; it does not exec nginx
     # itself (the base entrypoint does), so it ends after `nginx -t`.

package/deploy/compose/gateway-watchdog.sh

@@ -7,6 +7,10 @@
 #   chmod +x /opt/exe-stack/gateway-watchdog.sh
 #   crontab -l | { cat; echo "*/2 * * * * /opt/exe-stack/gateway-watchdog.sh 2>&1 | logger -t exe-gw-watchdog"; } | crontab -
 #
+#   Or via Ansible (preferred — this header alone was never enough; see bug
+#   b5b01c2d, part 2: the install line above documented here was never actually
+#   run on exe-db-jkt): import_tasks: deploy/ansible/tasks/gateway-watchdog-cron.yml
+#
 # ─────────────────────────────────────────────────────────────────────────────
 # BUG HISTORY (facd5078, P0)
 # ─────────────────────────────────────────────────────────────────────────────
@@ -54,12 +58,25 @@ COOLDOWN_SECS="${EXE_GATEWAY_WATCHDOG_COOLDOWN_SECS:-300}"
 STATE_DIR="${EXE_GATEWAY_WATCHDOG_STATE_DIR:-${STACK_DIR}/.gateway-watchdog}"
 STRIKE_FILE="${STATE_DIR}/strikes"
 LAST_RESTART_FILE="${STATE_DIR}/last-restart"
+LAST_RUN_FILE="${STATE_DIR}/last-run"
 
 mkdir -p "$STATE_DIR" 2>/dev/null || true
 
 ts() { date -u +"%Y-%m-%dT%H:%M:%SZ"; }
 log() { echo "[$(ts)] gateway-watchdog: $*"; }
 
+# Heartbeat: proves the cron entry is actually firing, independent of what the
+# probe finds. strikes/last-restart only update on specific outcomes, so a
+# process that stopped being scheduled would leave them looking unremarkable
+# forever. This file updates on EVERY invocation — same "a monitor going quiet
+# must be detectable" pattern as backup.sh's LAST_STATUS file. A stale
+# last-run (older than a few cron intervals) means the cron stopped firing,
+# not that the gateway is healthy.
+write_heartbeat() {
+  printf 'last_run=%s\nepoch=%s\n' "$(ts)" "$(date -u +%s)" > "$LAST_RUN_FILE" 2>/dev/null || true
+}
+trap write_heartbeat EXIT
+
 # Read a single KEY=VALUE from the stack .env WITHOUT sourcing it (the .env holds
 # many secrets and arbitrary values; sourcing could execute / mangle them).
 read_env() {

package/deploy/compose/generate-env.ts

@@ -89,7 +89,17 @@ export const WIKI_IMAGE_TAG = pin("wiki", REGISTRY, "exe-wiki");
 // pinned the wiki to an empty schema — Prisma bootstraps it silently rather than
 // erroring, so the wiki simply comes up with no users and no documents.
 const WIKI_DB_SCHEMA = "public";
-const WIKI_VECTOR_DB = "exeOsMcp";
+// Bugs bed3cb4a / c604df37: exeOsMcp is not reachable in production (the wiki's
+// client spawns the wrong exe-os CLI subcommand) and exe-wiki PR #78 made
+// native + pgvector the working, self-contained default. See the matching
+// comment in deploy/compose/docker-compose.yml's exe-wiki environment block.
+const WIKI_VECTOR_DB = "pgvector";
+const WIKI_LLM_PROVIDER = "zai";
+const WIKI_ZAI_MODEL_PREF = "glm-4.6";
+const WIKI_ZAI_BASE_PATH = "https://api.z.ai/api/coding/paas/v4";
+// codex P1: docker-compose.yml reads the UNPREFIXED ZAI_MODEL_PREF / ZAI_BASE_PATH
+// (matching the already-unprefixed ZAI_API_KEY) — emit those names, not
+// WIKI_-prefixed ones a fresh customer .env would generate but compose never reads.
 const WIKI_HOST_PORT = "3001";
 export const EXE_OS_IMAGE_TAG = pin("exe-os", REGISTRY, "exe-os");
 export const GATEWAY_IMAGE_TAG = pin("gateway", REGISTRY, "exe-gateway");
@@ -313,7 +323,22 @@ export function generateEnv(options: GenerateEnvOptions): string {
     "# only thing holding production together was a host-local compose override.",
     "# exe-wiki-schema-guard blocks the boot if you get this wrong.",
     `WIKI_DB_SCHEMA=${WIKI_DB_SCHEMA}`,
+    "# Bugs bed3cb4a / c604df37 — see deploy/compose/docker-compose.yml's exe-wiki",
+    "# environment block for the full rationale. pgvector reuses this same",
+    "# exe-db instance; native runs in-process (no API key, no exe-os MCP daemon).",
     `WIKI_VECTOR_DB=${WIKI_VECTOR_DB}`,
+    "# bug bed3cb4a / corrected 2026-08-31 (founder direction): wiki's RAG/chat",
+    "# uses GLM via Z.ai directly (exe-wiki PR #78's real, verified `zai`",
+    "# provider) — not Anthropic through exe-gateway. Supply ZAI_API_KEY to match.",
+    `WIKI_LLM_PROVIDER=${WIKI_LLM_PROVIDER}`,
+    `ZAI_MODEL_PREF=${WIKI_ZAI_MODEL_PREF}`,
+    `ZAI_BASE_PATH=${WIKI_ZAI_BASE_PATH}`,
+    "# exe-gateway's /v1/messages authenticates via an exe_sk_* billing API key",
+    "# (exe-gateway src/api-keys.ts), provisioned per-customer through",
+    "# dashboard.askexe.com — it cannot be generated here. Chat/RAG will fail",
+    '# ("No Anthropic API key was set") until this is set.',
+    MANUAL_VALUE_COMMENT,
+    "WIKI_ANTHROPIC_API_KEY=",
     `WIKI_AUTH_TOKEN=${randomSecret(RANDOM_SECRET_48)}`,
     `EXE_WIKI_ADMIN_TOKEN=${randomSecret(RANDOM_SECRET_48)}`,
     `WIKI_JWT_SECRET=${randomSecret(RANDOM_SECRET_48)}`,
@@ -632,7 +657,22 @@ export function generateExampleEnv(): string {
     "# only thing holding production together was a host-local compose override.",
     "# exe-wiki-schema-guard blocks the boot if you get this wrong.",
     `WIKI_DB_SCHEMA=${WIKI_DB_SCHEMA}`,
+    "# Bugs bed3cb4a / c604df37 — see deploy/compose/docker-compose.yml's exe-wiki",
+    "# environment block for the full rationale. pgvector reuses this same",
+    "# exe-db instance; native runs in-process (no API key, no exe-os MCP daemon).",
     `WIKI_VECTOR_DB=${WIKI_VECTOR_DB}`,
+    "# bug bed3cb4a / corrected 2026-08-31 (founder direction): wiki's RAG/chat",
+    "# uses GLM via Z.ai directly (exe-wiki PR #78's real, verified `zai`",
+    "# provider) — not Anthropic through exe-gateway. Supply ZAI_API_KEY to match.",
+    `WIKI_LLM_PROVIDER=${WIKI_LLM_PROVIDER}`,
+    `ZAI_MODEL_PREF=${WIKI_ZAI_MODEL_PREF}`,
+    `ZAI_BASE_PATH=${WIKI_ZAI_BASE_PATH}`,
+    "# exe-gateway's /v1/messages authenticates via an exe_sk_* billing API key",
+    "# (exe-gateway src/api-keys.ts), provisioned per-customer through",
+    "# dashboard.askexe.com — it cannot be generated here. Chat/RAG will fail",
+    '# ("No Anthropic API key was set") until this is set.',
+    MANUAL_VALUE_COMMENT,
+    "WIKI_ANTHROPIC_API_KEY=CHANGEME_WIKI_ANTHROPIC_API_KEY",
     "WIKI_AUTH_TOKEN=CHANGEME_WIKI_AUTH_TOKEN",
     "EXE_WIKI_ADMIN_TOKEN=CHANGEME_EXE_WIKI_ADMIN_TOKEN",
     "WIKI_JWT_SECRET=CHANGEME_WIKI_JWT_SECRET",

package/deploy/compose/sso-edge/default.conf.template

@@ -70,54 +70,15 @@ map $http_cookie $sso_gotrue_cookie {
     "~(?:^|;\s*)exe_access_token=([^\s;]+)" $1;
 }
 
-# Static-asset exemption for the gate (see sso-redirect.conf step 0). Exempting
-# assets is required for the SPA to boot at all: the app sets its session cookie
-# only after its JS runs, so gating app.js hands a session-bearing document auth
-# HTML in place of its script -> blank page.
-#
-# MAPS OVER $request_uri, NOT $uri (bug 06a3daae). Same trap the token map
-# above documents: $sso_is_static is read inside the auth_request subrequest,
-# where $uri is the gate's own path `/_sso_gate` — never the original request
-# path — so an extension regex over $uri can never match and this exemption was
-# completely inert from the day it shipped. $request_uri IS inherited, but it
-# carries the query string, so the anchor admits `?`/`#` as well as end-of-
-# string — without that, /assets/app.js?v=abc would fall back into the gate.
-#
-# SCOPED BY PATH PREFIX, NOT BY BARE EXTENSION (P0 review of PR #874). A bare
-# extension test over $request_uri exempts ANY URL shaped like an asset, and the
-# app locations are catch-all proxies, so `/uploads/customer.png` and
-# `/api/export.js` would walk straight past the gate — the gate returns 204
-# before it ever looks at a cookie. The allow arms below are anchored at `^/`
-# on the build-output directories the SPAs actually boot from; everything else
-# — including every proxied application path — falls to `default ""` and stays
-# gated. This is now a path test AND an extension test, not a URL-shape test.
-#
-# nginx takes the FIRST matching regex in a map, so the deny arms are listed
-# first and win unconditionally over the allow arms.
-map $request_uri $sso_is_static {
-    default "";
-
-    # ── DENY (evaluated first, wins over everything below) ───────────────────
-    # Proxied application surface: API, user uploads and app-served files can
-    # never be exempt, whatever extension or query string they are dressed in.
-    "~*^/(?:api|uploads?|files|private|attachments|media|desk|app|method|admin)(?:[/?#]|$)" "";
-    # Traversal, raw or percent-encoded. $request_uri is the RAW request line:
-    # `/assets/../api/secret.js` is a prefix match here but normalizes to
-    # `/api/secret.js` before it reaches the app, so it must never be exempt.
-    "~\.\."   "";
-    "~*%2e"   "";
-    "~*%2f"   "";
-    "~*%5c"   "";
-
-    # ── ALLOW ────────────────────────────────────────────────────────────────
-    # Build-output directories only: Vite/Frappe `/assets/`, CRA/Twenty
-    # `/static/`, Next `/_next/static/`, Nuxt `/_nuxt/`, Vite-in-subdir
-    # `/build/assets/`. `[^?#]*` keeps the extension test on the PATH, so a
-    # query string can never supply the matching extension.
-    "~*^/(?:_next/static|_nuxt|assets|static|build/assets)/[^?#]*\.(?:js|mjs|css|map|png|jpe?g|gif|svg|ico|webp|woff2?|ttf)(?:[?#]|$)" "static";
-    # Root icons the browser requests on its own before any app code runs.
-    "~*^/(?:favicon\.(?:ico|svg|png)|apple-touch-icon(?:-precomposed)?\.png)(?:[?#]|$)" "static";
-}
+# NO static-asset exemption map here — deliberately (bug 419e1231). A
+# `map $uri $sso_is_static` used to live at this spot, feeding a step-0 bypass
+# in /_sso_gate that could never fire ($uri inside an auth_request subrequest is
+# "/_sso_gate", not the parent path). Since bug 83ba9546 the gate authenticates
+# off the apex `exe_sess` cookie, which the browser sends on the very first
+# request, so assets need no exemption to load. Do not re-add this map over
+# $request_uri "to make it work" — that would newly open a real bypass for every
+# path ending in an asset extension (CRM attachments, wiki images included).
+# Ungate a specific path with `location = /p { auth_request off; }` instead.
 
 map $http_upgrade $sso_conn_upgrade {
     default upgrade;
@@ -152,6 +113,12 @@ server {
     location = /health  { auth_request off; proxy_pass http://sso_crm/healthz; }
     location = /healthz { auth_request off; proxy_pass http://sso_crm/healthz; }
 
+    # Logout endpoint must be exempt from SSO gate (bug 96f8b2b2). Without this,
+    # /auth/logout triggers 401 -> redirect to auth with logout URL as redirect param
+    # -> infinite loop. Let the app handle logout (clear its own cookies), then it
+    # redirects to auth.askexe.com/logout for the central SSO cookie clear.
+    location = /auth/logout { auth_request off; proxy_pass http://sso_crm/auth/logout; }
+
     location / { proxy_pass http://sso_crm; }
 }
 
@@ -163,15 +130,25 @@ server {
     set $sso_auth_base      "https://auth.${DOMAIN}";
     set $sso_app_url        "https://wiki.${DOMAIN}";
     set $sso_product        "Wiki";
-    # Bug f1bb40d8: ONE canonical SSO session-cookie key across auth / edge / wiki.
-    # Previously the edge gated on $cookie_wiki_session while the wiki frontend set
-    # exe_sso_token (and kept its real token in localStorage) — four different keys,
-    # so the edge never saw a session and the user redirect-looped (yet /api/ping
-    # stayed 200, so health missed it). The contract is now exe_access_token: the
-    # wiki sets a cookie of this name after consuming ?access_token=, and the edge
-    # gates on the same name. Keep this in lockstep with EXE_SSO_COOKIE_NAME on the
-    # exe-wiki service (docker-compose.yml) and sso-redirect.README.md.
-    set $sso_session_cookie $cookie_exe_access_token; # exe-wiki SSO session cookie (canonical)
+    # Bug 4a6650f5: EMPTY ON PURPOSE — the wiki has no app-native session cookie.
+    #
+    # This used to be $cookie_exe_access_token (bug f1bb40d8's "one canonical SSO
+    # cookie key"), but exe_access_token is the apex PRESENCE SENTINEL: value is
+    # the literal "1", deliberately JS-readable, forgeable by any visitor. Using
+    # it here made step 1 of /_sso_gate satisfy its app-cookie arm and its
+    # sentinel arm from that single cookie, so `Cookie: exe_access_token=1`
+    # returned 204 with no credential at all (live: wiki 200 instead of 302), and
+    # a logged-out user could walk back in by re-setting it, defeating cross-app
+    # logout. exe-wiki never had a second, real session cookie to point at — its
+    # boot script only mirrors this same sentinel name (EXE_SSO_COOKIE_NAME).
+    #
+    # Leaving it empty makes step 1 unmatchable, so every wiki request falls
+    # through to steps 2-3 and is authenticated by the apex `exe_sess` cookie
+    # validated against GoTrue /user — the same path CRM/ERP take on first visit
+    # since bug 83ba9546, and strictly stronger than presence-trusting a cookie.
+    # If exe-wiki ever mints a real server-side session cookie, set that name
+    # here — never the sentinel.
+    set $sso_session_cookie "";
     include /etc/nginx/snippets/sso-redirect.conf;
 
     # Bug d3ba1136: wiki's actual health probe is /api/ping. Expose the standard
@@ -180,6 +157,9 @@ server {
     location = /health  { auth_request off; proxy_pass http://sso_wiki/api/ping; }
     location = /healthz { auth_request off; proxy_pass http://sso_wiki/api/ping; }
 
+    # Logout endpoint must be exempt from SSO gate (bug 96f8b2b2).
+    location = /auth/logout { auth_request off; proxy_pass http://sso_wiki/auth/logout; }
+
     location / { proxy_pass http://sso_wiki; }
 }
 
@@ -207,7 +187,27 @@ server {
     set $sso_session_cookie $cookie_sid;              # Frappe/ERPNext session cookie
     include /etc/nginx/snippets/sso-redirect.conf;
 
-    location / { proxy_pass http://sso_erp; }
+    # ERP is the one upstream that runs a realtime socket.io service with
+    # origin authentication: frappe's realtime middleware compares the Host
+    # header against the Origin header and rejects mismatches ("Invalid
+    # origin"), and the websocket upgrade needs explicit HTTP/1.1 + Upgrade
+    # headers. A bare proxy_pass sends Host: exe-erp-nginx and no upgrade
+    # headers, so every desk socket.io connection is rejected and the desk
+    # shows "Error connecting to socket.io: Invalid origin" (found in the
+    # 2026-09-02 four-domain demo verification).
+    location / {
+        proxy_pass http://sso_erp;
+        proxy_set_header Host $host;
+        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+        # Literal https, matching the template-level convention at the top of
+        # this file: this edge is reached via cloudflared over plain HTTP, so
+        # $scheme would report "http" for public HTTPS requests.
+        proxy_set_header X-Forwarded-Proto https;
+        proxy_http_version 1.1;
+        proxy_set_header Upgrade $http_upgrade;
+        proxy_set_header Connection "upgrade";
+        proxy_read_timeout 75s;
+    }
 }
 
 # ── Dashboard ────────────────────────────────────────────────────────────────
@@ -218,21 +218,49 @@ server {
     set $sso_auth_base      "https://auth.${DOMAIN}";
     set $sso_app_url        "https://dashboard.${DOMAIN}";
     set $sso_product        "Dashboard";
-    # The dashboard stores its access token in localStorage AND sets a cookie
-    # named exe_access_token on the parent domain so the SSO edge can gate on
-    # it (same cookie name as the Wiki — both are canonical SSO consumers).
-    set $sso_session_cookie $cookie_exe_access_token;
+    # Bug 4a6650f5: EMPTY ON PURPOSE — same defect and same fix as the Wiki
+    # vhost above (see its comment). The dashboard keeps its access token in
+    # localStorage and only mirrors the apex `exe_access_token` sentinel into a
+    # cookie; that sentinel is a forgeable "1", not a credential, so gating on it
+    # admitted anyone sending `Cookie: exe_access_token=1`. The dashboard has no
+    # app-native session cookie to name instead, so leave this empty and let
+    # steps 2-3 validate the apex `exe_sess` cookie against GoTrue.
+    set $sso_session_cookie "";
     include /etc/nginx/snippets/sso-redirect.conf;
 
     location = /health  { auth_request off; proxy_pass http://sso_dashboard/health; }
     location = /healthz { auth_request off; proxy_pass http://sso_dashboard/health; }
 
+    # Logout endpoint must be exempt from SSO gate (bug 96f8b2b2).
+    location = /auth/logout { auth_request off; proxy_pass http://sso_dashboard/auth/logout; }
+
     location / { proxy_pass http://sso_dashboard; }
 }
 
-# Default — unknown host → 404 (no open proxy).
+# Default — unknown host or edge-generated error → branded shared error pages
+# (packages/exe-error-pages, vendored here by packages/exe-error-pages/sync.mjs
+# and bind-mounted at /usr/share/nginx/html/error-pages; bug 64324162 delivery
+# path). Scoped to THIS server only: app 4xx/5xx from crm/wiki/erp/etc. are
+# proxied responses and pass through untouched (no proxy_intercept_errors).
 server {
     listen 80 default_server;
     server_name _;
-    return 404;
+
+    root /usr/share/nginx/html;
+
+    error_page 404          /error-pages/404.html;
+    error_page 500 502 504  /error-pages/500.html;
+    error_page 503          /error-pages/503.html;
+
+    # The shared pages, reachable only via the error_page directives above.
+    location ^~ /error-pages/ {
+        internal;
+        # Static HTML, inline CSS; Google Fonts is the only external dep.
+        add_header Cache-Control "no-store" always;
+    }
+
+    # Any request to an unconfigured host falls here and returns the branded 404.
+    location / {
+        return 404;
+    }
 }

package/deploy/compose/sso-edge/error-pages/404.html

@@ -0,0 +1,129 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <meta charset="UTF-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0">
+  <!-- Build provenance: stamped by stamp.mjs at delivery-build time so a served page reveals the exact source commit. Unstamped (literal __EXE_BUILD_*__) => served straight from git without a provenance step. -->
+  <meta name="exe-build-rev" content="__EXE_BUILD_REV__">
+  <meta name="exe-build-ref" content="__EXE_BUILD_REF__">
+  <meta name="exe-build-time" content="__EXE_BUILD_TIME__">
+  <title>404 — Page Not Found | Exe</title>
+  <style>
+    @import url('https://fonts.googleapis.com/css2?family=Epilogue:wght@400;700&family=Manrope:wght@400;500;600&display=swap');
+
+    *, *::before, *::after {
+      margin: 0;
+      padding: 0;
+      box-sizing: border-box;
+    }
+
+    body {
+      background: #0F0E1A;
+      color: #FFFFFF;
+      font-family: 'Manrope', sans-serif;
+      min-height: 100vh;
+      display: flex;
+      flex-direction: column;
+      align-items: center;
+      justify-content: center;
+      -webkit-font-smoothing: antialiased;
+      -moz-osx-font-smoothing: grayscale;
+    }
+
+    .container {
+      text-align: center;
+      padding: 2rem;
+      max-width: 480px;
+    }
+
+    .logo {
+      font-family: 'Epilogue', sans-serif;
+      font-weight: 700;
+      font-size: 30px;
+      color: #F5D76E;
+      letter-spacing: 0.08em;
+      margin-bottom: 3rem;
+    }
+
+    .error-code {
+      font-family: 'Epilogue', sans-serif;
+      font-weight: 700;
+      font-size: 120px;
+      line-height: 1;
+      color: #FFFFFF;
+      margin-bottom: 1rem;
+    }
+
+    .description {
+      font-family: 'Manrope', sans-serif;
+      font-size: 16px;
+      font-weight: 400;
+      color: #A09CAF;
+      line-height: 1.6;
+      margin-bottom: 2.5rem;
+    }
+
+    .btn {
+      display: inline-block;
+      font-family: 'Manrope', sans-serif;
+      font-weight: 600;
+      font-size: 14px;
+      letter-spacing: 0.04em;
+      text-transform: uppercase;
+      color: #0F0E1A;
+      background: #F5D76E;
+      border: none;
+      border-radius: 8px;
+      padding: 14px 36px;
+      cursor: pointer;
+      text-decoration: none;
+      transition: background 0.2s ease, transform 0.1s ease;
+    }
+
+    .btn:hover {
+      background: #f7e08a;
+      transform: translateY(-1px);
+    }
+
+    .btn:active {
+      transform: translateY(0);
+    }
+
+    .services {
+      margin-top: 4rem;
+      font-family: 'Manrope', sans-serif;
+      font-size: 13px;
+      color: #5A5669;
+    }
+
+    .services a {
+      color: #5A5669;
+      text-decoration: none;
+      transition: color 0.2s ease;
+    }
+
+    .services a:hover {
+      color: #A09CAF;
+    }
+
+    .services .sep {
+      margin: 0 0.6em;
+    }
+  </style>
+</head>
+<body>
+  <div class="container">
+    <div class="logo">EXE</div>
+    <div class="error-code">404</div>
+    <p class="description">The page you're looking for doesn't exist or has been moved.</p>
+    <a href="/" class="btn">Go Home</a>
+    <div class="services">
+      <a href="https://crm.askexe.com">CRM</a>
+      <span class="sep">&middot;</span>
+      <a href="https://wiki.askexe.com">Wiki</a>
+      <span class="sep">&middot;</span>
+      <a href="https://erp.askexe.com">ERP</a>
+    </div>
+  </div>
+</body>
+</html>