fix(omp): report approvals without claiming Claude's hook set

Review follow-up. omp declared `hooks: 'always'`, which every consumer reads
as Claude's full hook set, so an omp session picked up behaviour it cannot
back. omp goes back to `hooks: 'none'`; `capabilities.approvalHookFile` is now
a separate, narrower capability with its own predicate,
`approvalHookAvailableForMode()` (local, non-adopted sessions only).

- An explicit `stop` wait on omp is a 400 again; `blocked` still works.
- omp inbox items are alert-only (`answerInTerminal`, no `approvalId` on the
  push), and only `permission_prompt` / `elicitation_complete` are accepted for
  an approval-only session.
- The module is installed from POST /api/quick-start too (new and existing
  cases, not Docker or remote) and on reboot-restore, after the launch
  pre-flight on both create paths. Claude's settings.local.json block and the
  Docker CLAUDE.md no longer land in omp workspaces.
- The generated module passes Bun's `tls: { rejectUnauthorized: false }` for an
  https CODEMAN_API_URL (checked against a `--https` server), clears the alert
  only when the last pending toolCallId resolves, sends reports in order,
  carries omp's policy `reason` as `message`, and imports HookAPI from
  `@oh-my-pi/pi-coding-agent/extensibility/hooks`.
- Every path component and the target file are lstat-checked.
- docs/omp-integration.md, verbs.md and the stock.ts comments updated.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

src/config/cli-registry/stock.ts

@@ -1661,9 +1661,11 @@ const DEEPSEEK: CliEntry = {
 };
 
 // OMP (`omp`, omp.sh). The plainest entry in the catalog after opencode: no permission
-// flags at all — omp reads its model routing and hooks from `~/.omp/agent`, so the CLI's
-// own config governs and there is deliberately nothing bypass-shaped to clamp. Its only
-// privileged surface is a pair of ENV keys (see privilegedEnvKeys below).
+// flags at all — omp reads its model routing, approval mode and user hooks from
+// `~/.omp/agent`, so the CLI's own config governs and there is deliberately nothing
+// bypass-shaped to clamp. The one thing Codeman adds is a project hook module that
+// reports approval dialogs (`approvalHookFile` below). Its only privileged surface is a
+// pair of ENV keys (see privilegedEnvKeys below).
 const OMP: CliEntry = {
   id: 'omp' as CliEntry['id'],
   label: 'OMP',
@@ -1745,17 +1747,15 @@ const OMP: CliEntry = {
     // omp emits REAL approval events (`tool_approval_requested` / `tool_approval_resolved`),
     // so an omp pane can report a pending dialog first-hand instead of by inference.
     // Codeman installs the hook module named by `approvalHookFile` into
-    // `<workspace>/.claude/hooks/pre/` when a session is created; it forwards those two
-    // events to /api/hook-event as `permission_prompt` / `elicitation_complete`, the same
-    // names claude's settings block sends, so the tab alert, the desktop notification and
-    // the Approvals Inbox work unchanged.
-    // ⚠️ 'always' rather than 'supervised': the report comes from a hook Codeman owns and
-    // installs (like claude's), not from a supervised-CLI status bridge.
-    // ⚠️ Only approvals are reported. `stop`/`idle_prompt` still come from `workDetect`
-    // below, which stays the source of truth for whether an omp pane is working or idle.
-    hooks: 'always',
-    // The hook module Codeman writes for this CLI. Declared as data so the session-create
-    // path asks "does this CLI declare a hook file?" instead of branching on an id.
+    // `<workspace>/.claude/hooks/pre/` when a session is created (both create paths); it
+    // forwards those two events to /api/hook-event as `permission_prompt` /
+    // `elicitation_complete`, so the tab alert, the desktop notification and an ALERT-ONLY
+    // Approvals Inbox item (answer in the terminal) work.
+    // ⚠️ `hooks` stays 'none' (inherited from agentDefaults): that value means Claude's full
+    // hook set (`stop`, `idle_prompt`, answerable dialogs, `.claude/settings.local.json`),
+    // and omp has none of it. `approvalHookFile` is the separate, narrower capability;
+    // `approvalHookAvailableForMode()` is its predicate. Idle stays screen-read via
+    // `workDetect` below.
     approvalHookFile: 'codeman-approval.ts',
     // Fullscreen alt-screen TUI, same shape as antigravity/grok: only the
     // tmux-attach-time smcup strip, not Ink's full erase-scrollback+DECSET strip.
@@ -1778,7 +1778,8 @@ const OMP: CliEntry = {
       promptGlyph: '╰─',
       workingLine: '[⠋⠙⠹⠸⠼⠴⠦⠧⠇⠏] [0-9hms ]+> |⎋ Working',
     },
-    // No permission prompts and no bypass flag, so nothing config-shaped to clamp — the
+    // No permission FLAGS (omp's approval mode lives in its own config, `tools.approvalMode`)
+    // and no bypass flag, so nothing config-shaped to clamp — the
     // whole privileged surface here is env-shaped.
     privilegedParams: [],
     // Where omp resolves its auth from. No known concrete exfiltration path today (omp

src/config/cli-registry/types.ts

@@ -508,10 +508,11 @@ export interface CliCapabilities {
    * Whether `stop`/`blocked` wait signals can ever fire for this CLI.
    *
    * ⚠️ A TRI-STATE, not a boolean, because for one CLI this is a per-SESSION question:
-   *   'none'       — no hook signals, ever (every external CLI, and `shell`).
-   *   'always'     — the CLI's signals are installed by Codeman and are unconditional:
-   *                  claude via a `.claude/settings.local.json` block, omp via the hook
-   *                  MODULE named by `approvalHookFile` below.
+   *   'none'       — no hook signals, ever (every external CLI, and `shell`). A CLI can
+   *                  still report approval dialogs alone through `approvalHookFile` below.
+   *   'always'     — the CLI installs Codeman's hooks (claude). Every consumer reads this
+   *                  as Claude's FULL hook set: `stop`, `idle_prompt`, answerable inbox
+   *                  items, and a `.claude/settings.local.json` block in the workspace.
    *   'supervised' — the CLI REPORTS its own idle/working/blocked state to a supervisor
    *                  over a generic env-gated contract, and Codeman is that supervisor
    *                  (deepseek, via deepseek-status-shim.ts). Definitive rather than
@@ -526,16 +527,17 @@ export interface CliCapabilities {
    */
   hooks: 'none' | 'always' | 'supervised';
   /**
-   * A CLI whose hooks are MODULES rather than a settings-file block names the file
-   * Codeman installs into its project hook directory.
+   * The hook MODULE Codeman installs into the workspace of a CLI that reports its
+   * approval dialogs, and nothing else, through hooks. Independent of `hooks` above.
    *
    * omp is the case that exists today: it loads `<cwd>/.claude/hooks/pre/*.ts`, and the
    * installed module forwards `tool_approval_requested`/`tool_approval_resolved` to
-   * `/api/hook-event` as `permission_prompt`/`elicitation_complete`, so an omp pane asking
-   * for approval raises the same tab alert, notification and Approvals Inbox item a claude
-   * pane does. Absent with `hooks: 'always'` means Claude's settings-file block.
+   * `/api/hook-event` as `permission_prompt`/`elicitation_complete`. What that earns
+   * (`approvalHookAvailableForMode()`): the `blocked` wait signal, a tab alert, a
+   * notification and an ALERT-ONLY inbox item (`answerInTerminal`). Never `stop`, never
+   * `idle_prompt`, never Approve/Deny keystrokes.
    *
-   * Declared as data, not a branch on the id, so the session-create path can ask
+   * Declared as data, not a branch on the id, so both create paths can ask
    * "does this CLI need a hook file installed?" (see cli-registry-no-id-branching).
    */
   approvalHookFile?: string;

src/hooks-config.ts

@@ -1690,38 +1690,56 @@ export const OMP_APPROVAL_HOOK_FILE = 'codeman-approval.ts';
 /**
  * Source of the hook that turns omp's own approval events into Codeman hook events.
  *
- * WHY this exists: omp declares `capabilities.hooks: 'always'` (stock registry) but
- * installs no Claude-style `settings.local.json` hook block — its hooks are modules.
- * Without this file `hooksAvailableForMode()` is true while nothing ever POSTs, so
- * `/api/approvals` stays empty, the tab never goes red and no notification fires: an
- * omp pane asking for tool approval is silent. Claude solves the same problem by
- * writing a `Notification: permission_prompt` block into `settings.local.json`.
+ * WHY this exists: omp installs no Claude-style `settings.local.json` hook block — its
+ * hooks are modules — so without this file an omp pane asking for tool approval is
+ * silent: `/api/approvals` stays empty, the tab never goes red and no notification
+ * fires. The registry declares it through `capabilities.approvalHookFile`, NOT
+ * `hooks: 'always'` (which would also promise `stop` and answerable dialogs).
  *
- * The mapping mirrors Claude's names exactly, because the server routes on them
+ * The mapping uses Claude's event names, because the server routes on them
  * (`APPROVAL_KIND_BY_EVENT` in web/routes/hook-event-routes.ts):
- *  - `tool_approval_requested` -> `permission_prompt` (opens the inbox item)
+ *  - `tool_approval_requested` -> `permission_prompt` (opens an alert-only inbox item)
  *  - `tool_approval_resolved`  -> `elicitation_complete` (resolves it, whether the user
  *    approved or denied, so a denied dialog does not leave a red tab forever)
  *
+ * Several calls in one batch can each wait on their own prompt, and the inbox keeps one
+ * item per session, so the module tracks pending `toolCallId`s and reports the close only
+ * when the last one resolves. That set drains because omp pairs every request with a
+ * resolve, an aborted prompt included (its approval wrapper emits `approved: false` from
+ * the catch, omp 18.18.6 `extensibility/extensions/wrapper.ts`); only omp dying mid-prompt
+ * skips it, which leaves the alert up exactly as it would without the set. Reports go out
+ * in order (one chain), so a fast approve cannot overtake the prompt that opened it.
+ *
+ * `reason` is omp's POLICY note (a restricted folder, a critical-pattern match), not the
+ * command, and is absent on an ordinary mode-raised prompt, so it rides `message`.
+ *
+ * HTTPS: `CODEMAN_API_URL` is loopback HTTPS with a self-signed certificate on `--https`
+ * and tailscale installs (Codeman's own hook curl passes `-k`, the DeepSeek shim sets
+ * `rejectUnauthorized: false`). omp runs on Bun, whose fetch verifies certificates by
+ * default, so an `https:` URL gets Bun's `tls: { rejectUnauthorized: false }`.
+ *
  * ⚠️ Fails OPEN and SILENT, like the memory-gate hook: a hook that throws would break
  * the approval flow it exists to report. Every path catches, and nothing is awaited
- * unbounded — the fetch is fire-and-forget with a short AbortSignal.
+ * unbounded — each POST carries a short AbortSignal and the handlers never await it.
  */
 export function generateOmpApprovalHook(): string {
   return `// ${OMP_APPROVAL_HOOK_MARKER} — auto-generated by Codeman; safe to delete, rewritten when a session is created.
 //
 // Reports omp's tool-approval dialogs to Codeman's /api/hook-event so an omp pane
-// raises a tab alert and a desktop notification exactly like a claude pane does.
+// raises a tab alert and a desktop notification. Answer the dialog in the terminal.
 // Codeman owns this file: a foreign file of the same name is never overwritten.
 import { readFile } from "node:fs/promises";
-import type { HookAPI } from "@oh-my-pi/pi-coding-agent";
+import type { HookAPI } from "@oh-my-pi/pi-coding-agent/extensibility/hooks";
 
 const API_URL = process.env.CODEMAN_API_URL;
 const SESSION_ID = process.env.CODEMAN_SESSION_ID;
 const SECRET_FILE = process.env.CODEMAN_HOOK_SECRET_FILE;
+// Loopback HTTPS (--https, tailscale) uses a self-signed certificate, which Bun's fetch
+// refuses by default; Codeman's own hook curl passes -k for the same reason.
+const TLS = API_URL?.startsWith("https:") ? { tls: { rejectUnauthorized: false } } : {};
 
-/** POST one Codeman hook event. Never throws, never awaited past its timeout. */
-async function report(event: string, data: Record<string, unknown>): Promise<void> {
+/** POST one Codeman hook event. Never throws; bounded by its timeout. */
+async function send(event: string, data: Record<string, unknown>): Promise<void> {
   if (!API_URL || !SESSION_ID) return;
   try {
     const secret = SECRET_FILE ? (await readFile(SECRET_FILE, "utf8")).trim() : "";
@@ -1730,22 +1748,38 @@ async function report(event: string, data: Record<string, unknown>): Promise<voi
       headers: { "Content-Type": "application/json", "X-Codeman-Hook-Secret": secret },
       body: JSON.stringify({ event, sessionId: SESSION_ID, data }),
       signal: AbortSignal.timeout(5000),
+      ...TLS,
     });
   } catch {
     // Best effort by contract: a failed report must never disturb the dialog itself.
   }
 }
 
+// One chain, so reports arrive in the order omp raised them: a fast approve must not
+// overtake the prompt it answers and leave the alert up.
+let chain: Promise<void> = Promise.resolve();
+function report(event: string, data: Record<string, unknown>): void {
+  chain = chain.then(() => send(event, data));
+}
+
 export default function codemanApprovalHook(pi: HookAPI): void {
+  // Calls in one batch can each wait on their own prompt, and Codeman keeps one alert per
+  // session, so it is cleared only when the LAST pending approval resolves.
+  const pending = new Set<string>();
+
   pi.on("tool_approval_requested", (event) => {
-    void report("permission_prompt", {
+    pending.add(event.toolCallId);
+    // \`reason\` is omp's policy note (restricted folder, critical pattern), not the command.
+    report("permission_prompt", {
       tool_name: event.toolName,
-      tool_input: event.reason ? { description: event.reason } : undefined,
+      ...(event.reason ? { message: event.reason } : {}),
     });
   });
 
   pi.on("tool_approval_resolved", (event) => {
-    void report("elicitation_complete", {
+    pending.delete(event.toolCallId);
+    if (pending.size > 0) return;
+    report("elicitation_complete", {
       tool_name: event.toolName,
       approved: event.approved,
     });
@@ -1762,7 +1796,9 @@ export type ApprovalHookApplyResult = 'installed' | 'refreshed' | 'unchanged' |
  * Ownership: the file carries `OMP_APPROVAL_HOOK_MARKER` in its first line. A file
  * WITHOUT the marker is somebody else's hook and is left untouched (`foreign`) — the
  * same posture `installAgentSkillInto` takes, so Codeman never clobbers user work.
- * A symlinked directory is refused rather than written through.
+ * EVERY component below the workspace (`.claude`, `.claude/hooks`, `.claude/hooks/pre`)
+ * and the target file itself is `lstat`ed, and a symlink anywhere is refused rather than
+ * written through: a linked `.claude/hooks` once put `pre/<file>` in the link's target.
  *
  * Idempotent: an unchanged file is not rewritten (`unchanged`), so this is safe to call
  * on every omp session create.
@@ -1771,7 +1807,11 @@ export async function applyApprovalHookFile(workspace: string, fileName: string)
   const hookDir = join(workspace, OMP_APPROVAL_HOOK_DIR);
   const target = join(hookDir, fileName);
   return withSettingsLock(target, async () => {
-    if ((await isSymlink(hookDir)) || (await isSymlink(join(workspace, '.claude')))) return 'symlink';
+    let component = workspace;
+    for (const part of [...OMP_APPROVAL_HOOK_DIR.split('/'), fileName]) {
+      component = join(component, part);
+      if (await isSymlink(component)) return 'symlink';
+    }
 
     let existing: string | null = null;
     try {

src/web/routes/hook-event-routes.ts

@@ -13,11 +13,24 @@ import { HookEventSchema, isValidWorkingDir } from '../schemas.js';
 import { sanitizeHookData, parseBody } from '../route-helpers.js';
 import { persistDockerCaseClaudeSessionId } from '../../docker-hosts.js';
 import { getDataDir } from '../../config/instance.js';
-import { sessionWaits, hooksAvailableForMode, sessionHookOptions } from '../session-wait-registry.js';
+import {
+  sessionWaits,
+  hooksAvailableForMode,
+  approvalHookAvailableForMode,
+  sessionHookOptions,
+} from '../session-wait-registry.js';
 import { getCli } from '../../config/cli-registry/registry.js';
 import { approvalInbox, type ApprovalKind } from '../approval-inbox.js';
 import type { SessionPort, EventPort, RespawnPort, ConfigPort, InfraPort } from '../ports/index.js';
 
+/**
+ * The only events an approval-only hook module (`capabilities.approvalHookFile`, omp)
+ * sends: a dialog opened, and a dialog closed. Anything else claimed for such a session
+ * (`stop`, `idle_prompt`) is a signal it can never legitimately emit, so it is dropped
+ * like any other mode-gated forgery.
+ */
+const APPROVAL_HOOK_EVENTS = new Set(['permission_prompt', 'elicitation_complete']);
+
 /** Hook events that open an Approvals Inbox item. */
 const APPROVAL_KIND_BY_EVENT: Record<string, ApprovalKind> = {
   permission_prompt: 'permission',
@@ -93,12 +106,21 @@ export function registerHookEventRoutes(
     // could never legitimately emit one is now dropped instead of steering another
     // agent's control flow.
     const waitSession = ctx.sessions.get(sessionId);
+    // An approval-only session (omp) reports dialogs and nothing else, so it reaches the
+    // `blocked` half of the gate and never the `stop` half.
+    const approvalOnly =
+      !!waitSession &&
+      !hooksAvailableForMode(waitSession.mode, sessionHookOptions(waitSession)) &&
+      approvalHookAvailableForMode(waitSession.mode, sessionHookOptions(waitSession)) &&
+      APPROVAL_HOOK_EVENTS.has(event);
     if (waitSession && hooksAvailableForMode(waitSession.mode, sessionHookOptions(waitSession))) {
       if (event === 'stop') {
         sessionWaits.notifySignal(sessionId, 'stop');
       } else if (event === 'permission_prompt' || event === 'elicitation_dialog') {
         sessionWaits.notifySignal(sessionId, 'blocked');
       }
+    } else if (approvalOnly && event === 'permission_prompt') {
+      sessionWaits.notifySignal(sessionId, 'blocked');
     }
 
     // Signal the respawn controller based on hook event type
@@ -195,7 +217,7 @@ export function registerHookEventRoutes(
     // replacement would forget the item was unseen, or that a person had seen it). With no idle
     // item pending, the keep-alive's idle prompt opens a pre-acknowledged one.
     const keepsPendingIdle = keepAliveReason !== undefined && approvalInbox.getForSession(sessionId)?.kind === 'idle';
-    if (session && hooksAvailableForMode(session.mode, sessionHookOptions(session))) {
+    if (session && (hooksAvailableForMode(session.mode, sessionHookOptions(session)) || approvalOnly)) {
       if (approvalKind === 'idle' && keepsPendingIdle) {
         // Left in place: no new item, and the broadcast below carries the keep-alive reason.
       } else if (approvalKind) {
@@ -214,10 +236,12 @@ export function registerHookEventRoutes(
           toolSummary: typeof toolSummary === 'string' ? toolSummary : undefined,
           message: typeof safeData.message === 'string' ? safeData.message : undefined,
           cwd: typeof safeData.cwd === 'string' ? safeData.cwd : undefined,
-          // Supervised-hook CLIs (DeepSeek Harness): dialog keystrokes are unverifiable,
-          // so the item is an alert — answer in the terminal. Capability-gated, not by
-          // mode id, so a future supervised CLI inherits the same shape.
-          answerInTerminal: getCli(session.mode)?.capabilities.hooks === 'supervised',
+          // Supervised-hook CLIs (DeepSeek Harness) and approval-only hook modules (omp):
+          // dialog keystrokes are unverifiable (the inbox's re-capture parses Claude's
+          // numbered dialog only, and omp's composer keeps taking typing while its prompt
+          // is docked, so a `1` would land there), so the item is an alert — answer in
+          // the terminal. Capability-gated, not by mode id.
+          answerInTerminal: getCli(session.mode)?.capabilities.hooks === 'supervised' || approvalOnly,
           // What the pane says is still running in the background. An idle prompt from a
           // session that is watching its own work opens acknowledged, so it never arms an
           // alert nobody can answer; notePrompt() carries the whole reasoning.
@@ -268,9 +292,12 @@ export function registerHookEventRoutes(
         sessionId,
         sessionName,
         ...safeData,
-        // Supervised-hook CLIs answer in the terminal: omit approvalId so push
-        // cannot offer Approve/Deny that the answer route would refuse.
-        ...(approvalId && session && getCli(session.mode)?.capabilities.hooks !== 'supervised' && { approvalId }),
+        // Supervised-hook CLIs and approval-only modules answer in the terminal: omit
+        // approvalId so push cannot offer Approve/Deny that the answer route would refuse.
+        ...(approvalId &&
+          session &&
+          getCli(session.mode)?.capabilities.hooks !== 'supervised' &&
+          !approvalOnly && { approvalId }),
       });
     }
 

src/web/routes/reboot-restore-routes.ts

@@ -42,7 +42,12 @@ import { clampEnvOverridesForOwner } from '../../session-env-clamp.js';
 import { Session } from '../../session.js';
 import { resolveClaudeModeForUsername } from '../../user-store.js';
 import { getCli } from '../../config/cli-registry/registry.js';
-import { agentSkillDir, applyWorkspaceHooks, seedAgentSessionPreamble } from '../../hooks-config.js';
+import {
+  agentSkillDir,
+  applyApprovalHookFile,
+  applyWorkspaceHooks,
+  seedAgentSessionPreamble,
+} from '../../hooks-config.js';
 import { getLifecycleLog } from '../../session-lifecycle-log.js';
 import { STATS_COLLECTION_INTERVAL_MS } from '../../config/server-timing.js';
 import { SseEvent } from '../sse-events.js';
@@ -260,6 +265,17 @@ export function registerRebootRestoreRoutes(app: FastifyInstance, ctx: RebootRes
               console.warn(`[reboot-restore] hook install failed for ${session.workingDir}: ${getErrorMessage(err)}`)
             );
           }
+          // Same reasoning for a CLI that reports approvals through a hook MODULE (omp,
+          // `approvalHookFile`): a deleted or recreated workspace would leave the restored
+          // pane's approval dialogs silent. Local-only is structural here (see below).
+          const approvalHookFile = getCli(session.mode)?.capabilities.approvalHookFile;
+          if (workspaceHooksEnabled && approvalHookFile) {
+            await applyApprovalHookFile(session.workingDir, approvalHookFile).catch((err: unknown) =>
+              console.warn(
+                `[reboot-restore] approval hook install failed for ${session.workingDir}: ${getErrorMessage(err)}`
+              )
+            );
+          }
 
           // Both create paths seed this; without it a restored claude session's agent
           // skill falls back to writing out the whole ~150-line §0 preamble. Remote and

src/web/routes/session-routes.ts

@@ -1090,6 +1090,19 @@ export function registerSessionRoutes(
   /** Test seam: inject a registry with fake IO instead of the real TCP/WoL probes. */
   options: { remoteWake?: RemoteWakeRegistry } = {}
 ): RemoteWakeRegistry {
+  /**
+   * Install the approval hook MODULE a CLI declares (`capabilities.approvalHookFile`,
+   * omp) into a LOCAL workspace, so its approval dialogs raise an alert. Shared by
+   * POST /api/sessions and POST /api/quick-start so the two cannot drift; callers own
+   * the remote/Docker/named-workspace conditions and call it only after the launch
+   * pre-flight. Gated on `workspaceHooksEnabled` like Claude's block. Best-effort: a
+   * failure here must not fail the create.
+   */
+  const installApprovalHook = async (mode: SessionMode, workspace: string): Promise<void> => {
+    const fileName = getCli(mode)?.capabilities.approvalHookFile;
+    if (!fileName || !(await ctx.getWorkspaceHooksEnabled())) return;
+    await applyApprovalHookFile(workspace, fileName).catch(() => {});
+  };
   // Wake-on-LAN for sleeping remote hosts (see remote-wake.ts). One registry per
   // route registration (= one web server) — the same shape as the process-wide
   // `sessionWaits` singleton, but without the global.
@@ -1332,18 +1345,6 @@ export function registerSessionRoutes(
       await applyWorkspaceHooks(workingDir, await ctx.getWorkspaceHooksEnabled());
     }
 
-    // A CLI whose hooks are MODULES rather than a settings.local.json block (omp) needs
-    // its hook file installed into the workspace, so its approval dialogs raise the same
-    // alert a claude pane does. Registry-driven: `approvalHookFile` names the file, so no
-    // call site branches on a CLI id. Same local-workspace and `workspaceHooksEnabled`
-    // gate as claude's block; best-effort, because a failure here must not block a create.
-    const approvalHookFile = getCli(body.mode ?? 'claude')?.capabilities.approvalHookFile;
-    if (!remote && body.workingDir && approvalHookFile) {
-      if (await ctx.getWorkspaceHooksEnabled()) {
-        await applyApprovalHookFile(workingDir, approvalHookFile).catch(() => {});
-      }
-    }
-
     // Refuse up front if the requested CLI cannot start, rather than spawning a pane that
     // dies on `command not found`. The message comes from the resolver, so it names where
     // resolution actually looked (server PATH, login shell, the entry's search dirs); a
@@ -1365,6 +1366,13 @@ export function registerSessionRoutes(
       }
     }
 
+    // Approval hook module (omp): after the pre-flight, like the agent skill below, so a
+    // CLI that cannot start leaves nothing in the workspace. Same remote and
+    // named-workingDir conditions as the hooks above.
+    if (!remote && body.workingDir) {
+      await installApprovalHook(body.mode ?? 'claude', workingDir);
+    }
+
     // Agent skill (docs/agent-control-plan.md §2): ADD-ONLY on create, same shared-
     // workspace rationale as the statusLine above: a create must never remove the
     // skill from under other live sessions in the repo. Marker-guarded, so a user's
@@ -4643,6 +4651,13 @@ export function registerSessionRoutes(
       }
     }
 
+    // Approval hook module (omp), for a new AND an existing case. The launch pre-flight
+    // above has passed. Local only: a remote case path lives on another host, and a Docker
+    // pane cannot reach the loopback API (`approvalHookAvailableForMode()` answers no there).
+    if (!remote && !docker) {
+      await installApprovalHook(mode, workspacePath);
+    }
+
     // Agent skill injection (docs/agent-control-plan.md §2): ADD-ONLY on create,
     // marker-guarded (a user's own copy is never touched). Each CLI that takes the
     // skill gets it in the directory it scans (`capabilities.agentSkillDir`:

src/web/session-wait-registry.ts

@@ -295,15 +295,38 @@ export function sessionHookOptions(session: {
 
 /**
  * Whether `blocked` can ever fire for this session: its CLI reports it through hooks
- * (`hooksAvailableForMode()`), or Codeman reads the dialogs it blocks on off its screen
- * (`capabilities.workDetect.blockedLine`, codex). The screen half needs no per-session
- * facts: a remote or Docker pane is still a local tmux pane showing the CLI's screen
- * (their nested tmux runs with `status off`, so nothing is drawn below the CLI).
+ * (`hooksAvailableForMode()`), through an approval-only hook module
+ * (`approvalHookAvailableForMode()`, omp), or Codeman reads the dialogs it blocks on off
+ * its screen (`capabilities.workDetect.blockedLine`, codex). The screen half needs no
+ * per-session facts: a remote or Docker pane is still a local tmux pane showing the CLI's
+ * screen (their nested tmux runs with `status off`, so nothing is drawn below the CLI).
  *
  * ⚠️ Says nothing about `stop`. A screen shows a dialog; it never says a turn ended.
  */
 export function blockedSignalAvailable(mode: SessionMode, options: HookCapabilityOptions = {}): boolean {
-  return hooksAvailableForMode(mode, options) || !!getCli(mode)?.capabilities.workDetect?.blockedLine;
+  return (
+    hooksAvailableForMode(mode, options) ||
+    approvalHookAvailableForMode(mode, options) ||
+    !!getCli(mode)?.capabilities.workDetect?.blockedLine
+  );
+}
+
+/**
+ * Whether this session reports its approval dialogs, and ONLY those, through a hook
+ * module Codeman installed into its workspace (`capabilities.approvalHookFile`, omp).
+ *
+ * Deliberately separate from `hooksAvailableForMode()`: its consumers read a yes as
+ * "this CLI has Claude's full hook set", so `stop` would be accepted and never fire, and
+ * the inbox would offer Approve/Deny keystrokes it cannot verify. A yes HERE means
+ * `blocked` can fire and a dialog opens an alert-only inbox item, nothing more.
+ *
+ * Per-session like the supervised bridge: the module is installed only into a LOCAL
+ * workspace Codeman created the session in, so an adopted pane, a remote attach and a
+ * Docker case (`deepSeekBridgeUnreachable`, set for both) never have one.
+ */
+export function approvalHookAvailableForMode(mode: SessionMode, options: HookCapabilityOptions = {}): boolean {
+  if (options.adopted || options.deepSeekBridgeUnreachable) return false;
+  return !!getCli(mode)?.capabilities.approvalHookFile;
 }
 
 /** Outcome of resolving a caller-supplied wait target against a session's mode. */