@junghanacs/entwurf 0.21.0 → 0.22.0

package/pi-extensions/lib/codex-caller-seat.ts

@@ -0,0 +1,204 @@
+/**
+ * codex-caller-seat — the ONE resolution of a Codex caller's `threadId` into the tmux pane its
+ * TUI is sitting in. Narrow leaf of the fresh-call composition (#95 lane B); it owns the title
+ * anchor and the pane count and NOTHING else — it never runs tmux (the runner is injected),
+ * never phrases a placement decision, never reads a record, and has no fallback seat.
+ *
+ * Same shape and same discipline as `resolve-tmux-session.ts` and `classify-tmux-cwd.ts`: this
+ * file imports nothing at all, not even a node builtin, so it stays deletable on its own and
+ * cannot acquire an opinion about mux, entwurf, identity or delivery. The injected runner is
+ * matched STRUCTURALLY to `mux-placement.TmuxRun` rather than by a type import, for the same
+ * reason.
+ *
+ * ── WHAT THIS IS NOT ──
+ *
+ * A pane title is OPERATOR-WRITABLE and forgeable: any process in any pane can emit the same
+ * OSC 0 string. So this leaf's answer is a PLACEMENT INPUT and nothing else — the `$session`
+ * it returns may only reach a `-t` target. Identity, delivery and liveness keep the record +
+ * `_meta` join they already have (AGENTS.md Hard Rule 16). Nothing here reads screen text,
+ * sends keys, or infers that a citizen is alive.
+ *
+ * ── THE ANCHOR, AND WHY IT IS NOT THE BARE UUID ──
+ *
+ * With `thread-id` in `[tui].terminal_title` (the `entwurf install-codex-terminal-title` atom)
+ * the vendor renders the thread UUID into the terminal title — but TRUNCATED. `[측정]
+ * 2026-09-16, thinkpad, codex-cli 0.153.4: a live TUI's `#{pane_title}` read back
+ * `tmp | 01a0a7f9-ed9c-7aa2-a4dd-b1a39...`, not the 36-char id. Source at `rust-v0.153.4`:
+ * `codex-rs/tui/src/chatwidget/status_surfaces.rs:892-894` renders `TerminalTitleItem::SessionId`
+ * through `truncate_terminal_title_part(value, 32)`, and `:1027-1043` keeps 29 graphemes and
+ * appends `...`. So the anchor set is TWO strings: the truncated form the vendor emits today,
+ * and the full id — accepted so that a vendor which later stops truncating passes unchanged
+ * rather than silently resolving nothing.
+ *
+ * `[측정]` 29 leading chars of a thread UUID are ASCII (`01a09ec6-e6de-7643-8571-f3261`, 29
+ * code points, 29 bytes — terra#1 2026-09-16 item 8), so counting code points here and
+ * graphemes there is the same count for every id this rail will ever see.
+ *
+ * `[측정]` `rust-v0.154.0` is unchanged on all three axes — the `thread-id` item
+ * (`title_setup.rs:81-83`), the 32-char truncation (`status_surfaces.rs:930-934`) and the
+ * ` | ` separator (`title_setup.rs:187-195`) — so this anchor is not pinned to one release.
+ *
+ * ── WHY TOKENS AND NOT ` | ` SEGMENTS ──
+ *
+ * The obvious rule is "one ` | `-separated segment equals the anchor". It has a vendor hole.
+ * `title_setup.rs:183-193 separator_from_previous` joins adjacent items with ` | ` EXCEPT when
+ * either side is the `activity` item (`Spinner`, `title_setup.rs:47-48`), which gets a plain
+ * space — and `status_surfaces.rs:330-343` computes that `previous` from the last RENDERED
+ * item, skipping any that resolved to `None`. So on a host whose operator list ends in
+ * `activity`, the installed atom appends `thread-id` right after it and a WORKING TUI renders
+ * `<spinner text> 01a0a7f9-…`: one segment, two values. Splitting each segment on a space and
+ * comparing TOKENS closes that hole and cannot open a new one — a false positive would need
+ * some other title item to render a string byte-identical to this thread's own id.
+ *
+ * ── WHY THE COUNT IS OVER PANES, NOT TOKENS ──
+ *
+ * One pane can legitimately show the same thread twice: an operator whose `terminal_title` also
+ * carries `thread-title` sees the full 36-char id there whenever the thread is unnamed
+ * (`status_surfaces.rs:776-786`), beside our truncated one. Two tokens, one pane, one thread —
+ * not an ambiguity. Ambiguity is TWO PANES claiming the same thread, and that is refused
+ * because picking either would seat a sibling by guess.
+ */
+
+/** Why a Codex caller's seat could not be resolved. Two stable literals — the consuming
+ * composition widens its own reject union with this type, so the strings are contract. */
+export type CodexCallerSeatRejectReason = "codex-caller-seat-unresolved" | "codex-caller-seat-ambiguous";
+
+/** The repair text for each refusal, owned by the leaf that decides it so the sentence an
+ * operator reads cannot drift away from the predicate that produced it (the same rule the
+ * Copilot/OMP/Codex preflight hints follow). */
+export const CODEX_CALLER_SEAT_HINT: Record<CodexCallerSeatRejectReason, string> = {
+	"codex-caller-seat-unresolved":
+		"no pane on this agent's own tmux server shows this Codex thread in its title, so there is no caller seat to open a sibling beside — the TUI may be on another tmux server or outside tmux entirely, its config may not carry `thread-id` in [tui].terminal_title (run `entwurf install-codex-terminal-title`, then `entwurf doctor-codex-terminal-title`), or that server may have `allow-set-title off`, which replaces every pane title with the hostname and hides the id [측정 2026-09-16]",
+	"codex-caller-seat-ambiguous":
+		"more than one pane on this agent's own tmux server shows this Codex thread in its title, so which one is the caller cannot be decided — nothing is opened rather than guessing a seat; close the stale duplicate and call again",
+};
+
+/** What the injected runner returns. Structurally identical to `mux-placement.TmuxRun`; kept as
+ * its own declaration so this leaf imports nothing. */
+export interface CodexCallerSeatRun {
+	status: number | null;
+	stdout: string;
+	stderr: string;
+}
+
+/** The pane a Codex caller is sitting in. `sessionId` is the only member a placement may use;
+ * `paneId` travels for receipts and diagnosis, never as an address. */
+export interface CodexCallerSeat {
+	paneId: string;
+	sessionId: string;
+	source: "codex-title-anchor";
+}
+
+export type CodexCallerSeatResult =
+	| { ok: true; seat: CodexCallerSeat }
+	| { ok: false; reason: CodexCallerSeatRejectReason };
+
+/** The vendor's per-item ceiling for `thread-id` (`status_surfaces.rs:892-894`). */
+export const CODEX_TITLE_ITEM_MAX_CHARS = 32;
+
+/** The two separators a rendered title can put between items: ` | ` for an ordinary pair, and a
+ * bare space when either neighbour is the `activity` indicator (`title_setup.rs:183-193`). */
+const TITLE_SEGMENT_SEPARATOR = " | ";
+const TITLE_TOKEN_SEPARATOR = " ";
+
+/**
+ * The vendor's `truncate_terminal_title_part`, reproduced (`status_surfaces.rs:1027-1043`).
+ * Code points stand in for graphemes — measured identical for every thread id (see header).
+ */
+export function truncateTerminalTitlePart(value: string, maxChars: number): string {
+	const chars = [...value];
+	if (chars.length <= maxChars || maxChars <= 3) return chars.slice(0, maxChars).join("");
+	return `${chars.slice(0, maxChars - 3).join("")}...`;
+}
+
+/**
+ * Every string a title may legitimately carry for this thread. The truncated form is what the
+ * vendor emits today; the full id is accepted so a future vendor that stops truncating keeps
+ * working without a code change here.
+ */
+export function codexTitleAnchors(threadId: string): string[] {
+	if (threadId.length === 0) {
+		throw new Error("codex-caller-seat: refusing to build an anchor for an empty threadId");
+	}
+	const truncated = truncateTerminalTitlePart(threadId, CODEX_TITLE_ITEM_MAX_CHARS);
+	return truncated === threadId ? [threadId] : [threadId, truncated];
+}
+
+/** Does this ONE pane title name the thread? Segment first, then token — see the header for the
+ * `activity`-adjacency hole a segment-only rule leaves open. */
+export function titleNamesThread(title: string, anchors: readonly string[]): boolean {
+	for (const segment of title.split(TITLE_SEGMENT_SEPARATOR)) {
+		for (const token of segment.split(TITLE_TOKEN_SEPARATOR)) {
+			if (anchors.includes(token)) return true;
+		}
+	}
+	return false;
+}
+
+/**
+ * The lookup argv. `-a` is the whole server because a Codex TUI is not required to be in the
+ * caller's own session — that asymmetry is exactly what this leaf exists to remove. The three
+ * fields are tab-separated so a title containing spaces (a project name, the spinner text)
+ * cannot be read as a new column.
+ */
+export function buildCodexCallerSeatArgs(): string[] {
+	return ["list-panes", "-a", "-F", "#{pane_id}\t#{session_id}\t#{pane_title}"];
+}
+
+/** One `list-panes` line back into its three fields, or `null` when it is not one. The title
+ * takes EVERYTHING after the second tab: splitting on every tab would truncate a title that
+ * ever carried one. */
+function parsePaneLine(line: string): { paneId: string; sessionId: string; title: string } | null {
+	const firstTab = line.indexOf("\t");
+	if (firstTab < 0) return null;
+	const secondTab = line.indexOf("\t", firstTab + 1);
+	if (secondTab < 0) return null;
+	const paneId = line.slice(0, firstTab);
+	const sessionId = line.slice(firstTab + 1, secondTab);
+	if (paneId.length === 0 || sessionId.length === 0) return null;
+	return { paneId, sessionId, title: line.slice(secondTab + 1) };
+}
+
+/**
+ * Resolve the pane a Codex caller's thread is displayed in, on whatever server the runner's
+ * environment names.
+ *
+ * ONE BOUNDED IMPRECISION, STATED RATHER THAN LAUNDERED (the same one
+ * `resolve-tmux-session.ts` carries): rc≠0 also covers "no server running on this socket". This
+ * leaf reads every rc≠0 as `codex-caller-seat-unresolved`, so a server that died between the
+ * caller's context proof and this lookup is reported under the narrower word. That is safe —
+ * both readings are refusals that mutate nothing, and the hint above names both — and it is
+ * preferred over matching tmux's own stderr text, which would pin this leaf to one vendor
+ * version's wording.
+ */
+export function resolveCodexCallerSeat(
+	threadId: string,
+	run: (args: string[]) => CodexCallerSeatRun,
+): CodexCallerSeatResult {
+	const anchors = codexTitleAnchors(threadId);
+	const result = run(buildCodexCallerSeatArgs());
+	// A signalled call is not tmux answering — it carries no information about any pane at all,
+	// so it must never be read as "the caller's TUI is not here".
+	if (result.status === null) {
+		throw new Error(`codex-caller-seat: the pane listing was killed by a signal: ${result.stderr.trim()}`);
+	}
+	if (result.status !== 0) return { ok: false, reason: "codex-caller-seat-unresolved" };
+
+	const matches: CodexCallerSeat[] = [];
+	for (const line of result.stdout.split("\n")) {
+		if (line.length === 0) continue;
+		const pane = parsePaneLine(line);
+		// A line this leaf cannot read is NOT a pane it may skip quietly: the listing is the
+		// whole evidence base for "exactly one", and a dropped line could be the second match
+		// that should have refused.
+		if (pane === null) {
+			throw new Error(`codex-caller-seat: tmux printed a pane line this leaf cannot read: ${JSON.stringify(line)}`);
+		}
+		if (titleNamesThread(pane.title, anchors)) {
+			matches.push({ paneId: pane.paneId, sessionId: pane.sessionId, source: "codex-title-anchor" });
+		}
+	}
+	if (matches.length === 0) return { ok: false, reason: "codex-caller-seat-unresolved" };
+	if (matches.length > 1) return { ok: false, reason: "codex-caller-seat-ambiguous" };
+	return { ok: true, seat: matches[0] };
+}

package/pi-extensions/lib/codex-fresh-preflight.ts

@@ -29,7 +29,40 @@ export const CODEX_PREFLIGHT_HINT: Record<CodexPreflightRejectReason, string> =
 	"codex-visible-identity-missing":
 		"Codex tui.status_line does not include thread-title; run `entwurf install-codex-statusline`, then `entwurf doctor-codex-statusline`",
 	"codex-app-server-unavailable":
-		"the operator-owned Codex app-server default socket is absent or unsafe; start `codex app-server --listen unix://$CODEX_HOME/app-server-control/app-server-control.sock` and retry",
+		"the operator-owned Codex app-server default socket is absent or unsafe; start it with `entwurf codex-app-server` from a detached tmux session (one that is NOT where you work), then retry",
+};
+
+/**
+ * THE CALLER AXIS, AND IT IS NOT THE ONE ABOVE. Everything above asks "can a Codex sibling be
+ * OPENED on this host" — birth unit, vendor trust, MCP hand, visible identity, app-server. This
+ * asks the opposite question: "can the Codex citizen DOING the opening be located", which is a
+ * fact about the CALLER's own config and is required no matter which backend it opens (#95
+ * lane B). Keeping them apart is the point: a Pi caller opening a Codex sibling needs the five
+ * above and none of this, and a Codex caller opening a Pi sibling needs this and none of those.
+ * Folding either into the other would refuse one operator for the other's missing repair.
+ */
+export type CodexCallerPreflightRejectReason = "codex-caller-title-missing";
+
+/**
+ * THE LAUNCH-DIRECTORY AXIS, AND IT IS A THIRD QUESTION AGAIN. The target axis asks "can a Codex
+ * sibling be opened on this host", the caller axis asks "can the Codex citizen doing the opening
+ * be located", and this asks "will the vendor START A TURN in the directory this launch names" —
+ * a fact about ONE directory rather than about the host or the caller, so it is the only axis
+ * that needs the resolved launch cwd and the only one that can pass for one call and refuse the
+ * next on an unchanged host.
+ */
+export type CodexLaunchCwdPreflightRejectReason = "codex-launch-cwd-undecided" | "codex-launch-cwd-untrusted-ancestor";
+
+export const CODEX_LAUNCH_CWD_PREFLIGHT_HINT: Record<CodexLaunchCwdPreflightRejectReason, string> = {
+	"codex-launch-cwd-undecided":
+		"Codex has recorded NO decision for the directory this sibling would start in, so the window would open on the vendor's folder-consent screen and WAIT for a human instead of running its first turn — no rollout, no callback, and nothing to address; either launch in a directory this Codex has already been answered for, or open a plain `codex -C <dir>` there once and answer it, then retry",
+	"codex-launch-cwd-untrusted-ancestor":
+		"this directory sits inside a project the operator marked `untrusted`, and on this rail the vendor does not offer a consent screen for that — it refuses the startup outright with `pass the repository root explicitly with --cd`, so answering a prompt at this directory would only reproduce that error; launch at that untrusted project's own root instead, or change that project's recorded decision",
+};
+
+export const CODEX_CALLER_PREFLIGHT_HINT: Record<CodexCallerPreflightRejectReason, string> = {
+	"codex-caller-title-missing":
+		"this Codex caller's tui.terminal_title does not include thread-id, so the multiplexer reports no pane title naming this thread and there is no caller seat to open the sibling beside; run `entwurf install-codex-terminal-title`, then `entwurf doctor-codex-terminal-title` (an explicit placement.tmuxSession skips this check entirely, because it never needs the seat)",
 };
 
 export interface CodexUnitPaths {
@@ -250,6 +283,190 @@ function visibleIdentityMissing(config: Record<string, unknown>): boolean {
 	return !Array.isArray(statusLine) || !statusLine.includes("thread-title");
 }
 
+/** `[tui].terminal_title` membership, the exact axis `entwurf doctor-codex-terminal-title`
+ * judges. Same shape as `visibleIdentityMissing` and a DIFFERENT key: `status_line` is what a
+ * human reads inside the TUI, `terminal_title` is what the multiplexer reports back as
+ * `#{pane_title}`. Neither substitutes for the other. */
+function callerTitleMissing(config: Record<string, unknown>): boolean {
+	const tui = config.tui;
+	if (tui == null || typeof tui !== "object" || Array.isArray(tui)) return true;
+	const terminalTitle = (tui as Record<string, unknown>).terminal_title;
+	return !Array.isArray(terminalTitle) || !terminalTitle.includes("thread-id");
+}
+
+/**
+ * The CALLER-side capability, pre-mutation and synchronous.
+ *
+ * Synchronous because it reads one config file and nothing else: there is no app-server axis
+ * here and there must not be one — whether the operator's app-server is up says nothing about
+ * whether a caller's pane can be found, and asking would make a placement check fail for a
+ * delivery reason.
+ *
+ * Call it only when the anchor will actually be USED — a codex caller that named an explicit
+ * `placement` never consults the title, so refusing it for a missing `thread-id` would be a
+ * refusal for an unused capability.
+ */
+export function codexCallerFreshPreflight(env: NodeJS.ProcessEnv): CodexCallerPreflightRejectReason | null {
+	const config = readConfig(env);
+	if (config === null || callerTitleMissing(config)) return "codex-caller-title-missing";
+	return null;
+}
+
+/**
+ * The launch directory's own capability, pre-mutation and synchronous — and DELIBERATELY NARROWER
+ * than the vendor's own decision, because the leaf that decides here reads one TOML file while the
+ * vendor asks its app-server. Read this whole comment as the scope statement it is: what follows
+ * says what this answers, and then says what it refuses to claim.
+ *
+ * WHY THE AXIS EXISTS. `[source rust-v0.153.4]` a fresh call always passes `--remote`, so the TUI
+ * resolves `AppServerTarget::Remote` and startup ALWAYS runs `check_directory_trust` on the `-C`
+ * value (`tui/src/lib.rs:1699-1725`). Nothing on that path consults the approval or sandbox policy
+ * (`tui/src/onboarding/directory_trust.rs:33-130`), which is why the
+ * `--dangerously-bypass-approvals-and-sandbox` token this argv already carries does NOT cover it:
+ * approvals and folder consent are two different gates. A directory with no recorded decision
+ * renders the consent screen and blocks, and a blocked TUI has started no turn — no rollout, no
+ * birth, no callback, and the caller waits out its whole timeout on a window that is merely
+ * waiting to be answered. `[측정 2026-09-16]` the two release-gate runs that failed launched in
+ * `…-2zznHl` and `…-kSsoAn`, neither of which had an entry; the two that passed launched in
+ * `…-db65N2` and `…-pBXxOJ`, both of which did. Unattended, the failure is silent.
+ *
+ * THE THREE VENDOR OUTCOMES THIS LEAF MODELS, in the vendor's own order
+ * (`tui/src/config_update.rs:290-371`, `ProjectTrustHost::Remote`):
+ *
+ *   1. A DIRECT decision on the exact cwd starts a turn, and BOTH recorded answers do. `trusted`
+ *      returns before any screen (`:346-354`); a saved `untrusted` is explicitly skipped for a
+ *      remote target — `if target.uses_remote_workspace() && trust_level == Some(Untrusted) {
+ *      continue; }` (`onboarding/directory_trust.rs:94-96`), and `uses_remote_workspace()` is
+ *      exactly `matches!(self, Self::Remote { .. })` (`tui/src/lib.rs:307-309`). Refusing a
+ *      deliberate `untrusted` would be entwurf inventing a policy the vendor does not have.
+ *      The key is the exact cwd — `cwd_keys = vec![cwd_key]` (`:290-296`), no root marker, no git
+ *      root, no parent, all three of which exist only on the Local host. `[측정 2026-09-16]`
+ *      `~/.codex/config.toml` carried a trusted `/tmp` and still recorded two separate
+ *      `/tmp/entwurf-codex-fresh-live-*` entries, one per run a human answered.
+ *   2. With NO direct decision, an enabled PROJECT LAYER consents on the directory's behalf
+ *      (`trust_level.is_none() && disabled_project.is_none() && project_layers.any(no
+ *      disabledReason)` → `Ok(None)`, `:346-354`). Those layers come from the app-server's
+ *      `ConfigRead { include_layers: true }` answer, which this leaf does not have. A layer that
+ *      is present but DISABLED is a fourth outcome — the vendor preserves an unknown or untrusted
+ *      project layer as disabled rather than dropping it, and that path falls through to the
+ *      screen — and this leaf cannot tell the two apart either. So wherever a layer could exist at
+ *      all it answers `null`, which folds both outcomes into "proceed".
+ *   3. With no direct decision and NO layers, a cwd inside an explicitly `untrusted` ancestor is
+ *      not a consent screen at all: the remote branch returns an ERROR
+ *      (`"remote project directory is inside an explicitly untrusted project; pass the repository
+ *      root explicitly with --cd"`, `:357-371`). That is a different failure with a different
+ *      repair, so it gets its own reason — answering `Trust` at the child would only reproduce the
+ *      same vendor error. Note the vendor's own precondition there is `project_layers.is_empty()`,
+ *      which is why this reason is only reachable after step 2 has found no layer anywhere.
+ *
+ * WHAT THIS LEAF IS FOR, AND WHAT IT IS NOT. It is NOT equivalent to the vendor's judgment and
+ * must not be described as asking "the same question": it reads the operator's own `config.toml`,
+ * while the vendor reads an EFFECTIVE config — system, managed and cloud layers merged around that
+ * user layer (`config/src/loader/mod.rs:258-290`, `:430-460`) — through its app-server.
+ *
+ * That gap is affordable because NOTHING HERE REFUSES A LAUNCH. `freshCall` prints what this leaf
+ * saw and opens the window anyway: the consent screen is self-repairing when a human is there, and
+ * one answer teaches the vendor the directory for good. The one caller that treats the answer as a
+ * precondition is `smoke-codex-fresh-live`, where nobody is at the keyboard and a named
+ * precondition is worth more than a callback timeout — that gate owns one directory, answered
+ * once.
+ *
+ * So read a non-null answer as "the vendor will probably stop here, and this is the repair", never
+ * as a verdict. Absence is not evidence either way, and every case this leaf cannot see resolves
+ * to `null`.
+ */
+export function codexLaunchCwdFreshPreflight(
+	env: NodeJS.ProcessEnv,
+	launchCwd: string,
+): CodexLaunchCwdPreflightRejectReason | null {
+	// THREE NON-ANSWERS, AND EVERY ONE OF THEM PROCEEDS. Each is a case where this leaf holds no
+	// evidence about what the vendor will do, and a refusal without evidence is exactly the false
+	// refusal this axis promises not to produce:
+	//
+	//   - A RELATIVE directory. It cannot match a stored key here, but the vendor does not give up
+	//     on one — it asks its app-server for a cwd and joins (`config_update.rs:203-224`), so the
+	//     joined path may well be answered. In production this branch is unreachable anyway: the
+	//     shared cwd leaf already refuses a non-absolute request as `cwd-not-absolute`, which is a
+	//     better reason than anything this axis could give.
+	//   - NO READABLE USER CONFIG. A missing `config.toml` is not "no decisions": the vendor loads
+	//     an empty user table and merges system, managed and cloud layers around it
+	//     (`config/src/loader/mod.rs:258-290`, `:430-460`, `:520-610`), any of which can carry the
+	//     decision or the layer that starts the turn.
+	//   - NO `projects` TABLE. Same reason: it says the USER layer records nothing, not that the
+	//     effective config does.
+	if (!path.isAbsolute(launchCwd)) return null;
+	const config = readConfig(env);
+	if (config === null) return null;
+	const projects = config.projects;
+	if (projects == null || typeof projects !== "object" || Array.isArray(projects)) {
+		return null;
+	}
+	const table = projects as Record<string, unknown>;
+	const levelOf = (key: string): string | null => {
+		const entry = table[key];
+		if (entry == null || typeof entry !== "object" || Array.isArray(entry)) return null;
+		const level = (entry as Record<string, unknown>).trust_level;
+		// An unrecognised value leaves `trust_level` as `None` on the vendor side too, and `None`
+		// with no project layer is precisely the case that renders the screen.
+		return level === "trusted" || level === "untrusted" ? level : null;
+	};
+	// Outcome 1: a direct decision, either answer.
+	if (levelOf(launchCwd) !== null) return null;
+	// Outcome 2: a PROJECT LAYER may consent with no entry at all, and this leaf cannot enumerate
+	// layers — they come from the app-server's `ConfigRead { include_layers: true }` answer. What
+	// it CAN decide is the negative: a `.codex` anywhere from the directory upward is the only
+	// place such a layer comes from, so when none exists the vendor's `project_layers` really is
+	// empty and the two remaining outcomes below are computable. Where one could exist, answer
+	// `null`.
+	//
+	// EXISTENCE, not ownership, and the weaker predicate is the load-bearing one. The vendor
+	// admits a layer on its own terms — an unknown or untrusted one is preserved as a DISABLED
+	// layer, not dropped — and none of that consults owner/mode/symlink safety. Asking for a
+	// safely-owned directory here would let a layer the vendor sees go unseen by this leaf, which
+	// would then synthesise an `untrusted-ancestor` refusal for a launch the vendor was going to
+	// run. That is the false refusal this axis must never produce, so the check is the widest
+	// thing that still means "a layer could live here".
+	//
+	// The operator's own CODEX HOME is excluded, and excluding it is what keeps this axis from
+	// being a no-op: `~/.codex` is an ancestor of nearly every directory anyone launches a sibling
+	// in, and it is the USER config root rather than a project layer — the vendor names those
+	// apart (`layer.name.dotCodexFolder` for a project, the home for the user layer). Counting it
+	// would answer `null` for every path under `$HOME` and the check would never fire in real use.
+	const codexHome = path.resolve(env.CODEX_HOME?.trim() || path.join(env.HOME ?? "", ".codex"));
+	for (let dir = launchCwd; ; ) {
+		const candidate = path.join(dir, ".codex");
+		if (candidate !== codexHome && fs.existsSync(candidate)) return null;
+		const parent = path.dirname(dir);
+		if (parent === dir) break;
+		dir = parent;
+	}
+	// Outcome 3: no layer anywhere and an explicitly untrusted ancestor — the vendor's own
+	// precondition for that branch is exactly `project_layers.is_empty()`, which the loop above
+	// has now established. It is reported as its own failure because its repair is to launch at
+	// that root, never to answer a prompt at the child.
+	//
+	// The MATCH IS NOT THE VENDOR'S and is not claimed to be. The vendor compares path URIs
+	// (`LegacyAppPathString` → `PathUri::starts_with`, segment-aware, fail-closed on encoded
+	// separators); this compares plain strings on a separator boundary. Where the two could
+	// disagree — a key or a cwd that is not a plain POSIX path — this answers `undecided` rather
+	// than `untrusted-ancestor`. Be exact about what that buys: BOTH are refusals, so this is NOT
+	// the launch-permissive direction. What it weakens is the SPECIFIC-ERROR claim — the ancestor
+	// reason names another directory as the repair, and naming the wrong one is worse than saying
+	// "no decision here". Neither vendor outcome on this branch starts a turn, so the guarantee
+	// above is untouched either way.
+	const plainPosixPath = (value: string): boolean =>
+		!value.includes("%") && !value.includes("\\") && !value.split("/").some((seg) => seg === "." || seg === "..");
+	if (plainPosixPath(launchCwd)) {
+		for (const key of Object.keys(table)) {
+			if (levelOf(key) !== "untrusted" || !plainPosixPath(key)) continue;
+			if (launchCwd === key || launchCwd.startsWith(key.endsWith("/") ? key : `${key}/`)) {
+				return "codex-launch-cwd-untrusted-ancestor";
+			}
+		}
+	}
+	return "codex-launch-cwd-undecided";
+}
+
 const DEFAULT_APP_SERVER_TIMEOUT_MS = 5_000;
 
 function withTimeout<T>(promise: Promise<T>, timeoutMs: number): Promise<T> {

package/pi-extensions/lib/entwurf-v2-runner.ts

@@ -12,8 +12,9 @@
  *
  * Why a result type richer than the receipt: the carry-over contracts from 5c demand it.
  *   - N3 (5c-2b): a dead-path re-resolve `rejected` carries the resolver's `rejectReason`
- *     (dormant-fire-forget-unsupported / mailbox-undeliverable / …). The runner carries it
- *     verbatim so the surface distinguishes "in-band refusal" from "no live route".
+ *     (dormant-fire-forget-unsupported / mailbox-undeliverable / …), while an in-band
+ *     refusal carries its supplied receiver error. The runner carries either verbatim;
+ *     receiver evidence is not reclassified as resolver taxonomy.
  *   - N1 (5c-2a): a non-`failed` outcome whose `releaseLock` then threw is a
  *     `SendDeliveredReleaseFailedError` — the delivery HAPPENED, the lock is dirty, a
  *     re-send would double-deliver. The runner surfaces this as `execution-failed` with

package/pi-extensions/lib/entwurf-v2-send.ts

@@ -101,12 +101,12 @@ export interface ControlSocketSendDeps {
 
 export interface ControlSocketSendResult {
 	outcome: SendFinalOutcome;
-	/** Present ONLY on a `rejected` outcome that came from the dead-path re-resolve
-	 * (5c-2b): the resolver's machine-readable reason (dormant-fire-forget-unsupported /
-	 * mailbox-undeliverable / indeterminate-no-spawn / bad-target / target-address-conflict).
-	 * An in-band RPC refusal carries NO reason (there is no resolver taxonomy for it). The
-	 * 5d runner carries this verbatim so the surface can tell "in-band refusal" from
-	 * "no live route" — the N3 carry-over the hand boundary used to drop. */
+	/** Present ONLY on a `rejected` outcome. It carries either the dead-path re-resolver's
+	 * machine-readable reason (dormant-fire-forget-unsupported / mailbox-undeliverable /
+	 * indeterminate-no-spawn / bad-target / target-address-conflict), or the non-empty
+	 * error returned by an in-band RPC/mailbox refusal. The latter is receiver evidence,
+	 * not a resolver taxonomy and is never invented when the completed result has no error.
+	 * The 5d runner carries this verbatim to the sender-visible surface. */
 	rejectReason?: string;
 	/** #98 R, fallback leg: the `.msg` a dead-socket re-resolve enqueued. Present ONLY
 	 * when the fallback actually routed to the mailbox and the enqueue succeeded — a
@@ -120,7 +120,7 @@ export interface ControlSocketSendResult {
 
 // A drive step's verdict: the terminal outcome, plus the original error to RETHROW on
 // a `failed` (the hand releases first, then rethrows — never swallows the failure), plus
-// the optional resolver reject reason to carry on a re-resolve `rejected` (N3).
+// the optional resolver or in-band receiver reason to carry on a `rejected` (N3).
 interface SendDrive {
 	outcome: SendFinalOutcome;
 	error?: unknown;
@@ -177,8 +177,9 @@ async function driveSend(plan: ControlSocketPlan, lock: LockClaim, deps: Control
 		// dead ⇒ proven non-delivery ⇒ same-lock one-shot re-resolve (lock still held).
 		return await driveDeadFallback(plan, lock, deps);
 	}
-	// A completed RPC: ack ⇒ sent; in-band refusal ⇒ rejected, NO fallback.
-	return { outcome: result.success ? "sent" : "rejected" };
+	// A completed RPC: ack ⇒ sent; in-band refusal ⇒ rejected, NO fallback. Preserve
+	// its receiver error verbatim when supplied; do not make a reason up when absent.
+	return result.success ? { outcome: "sent" } : inBandRejected(result);
 }
 
 /**
@@ -187,6 +188,10 @@ async function driveSend(plan: ControlSocketPlan, lock: LockClaim, deps: Control
  * re-enter the fallback, it finalizes as failed). The hand only executes; the resolver
  * decided.
  */
+function inBandRejected(result: RpcSendResult): SendDrive {
+	return { outcome: "rejected", rejectReason: result.error === "" ? undefined : result.error };
+}
+
 async function driveDeadFallback(
 	plan: ControlSocketPlan,
 	lock: LockClaim,
@@ -219,7 +224,7 @@ async function driveDeadFallback(
 			// connect failure finalizes as failed (no further fallback).
 			try {
 				const r = await deps.sendOverSocket(rePlan);
-				return { outcome: r.success ? "fallback-sent" : "rejected" };
+				return r.success ? { outcome: "fallback-sent" } : inBandRejected(r);
 			} catch (err) {
 				return { outcome: "failed", error: err };
 			}
@@ -231,7 +236,7 @@ async function driveDeadFallback(
 				// #98 R: this leg writes a `.msg` exactly like the primary mailbox rail, so it
 				// owes the sender the same per-message receipt. Carried only on success — a
 				// `rejected` enqueue wrote no file to name.
-				return r.success ? { outcome: "fallback-sent", messagePath: r.messagePath } : { outcome: "rejected" };
+				return r.success ? { outcome: "fallback-sent", messagePath: r.messagePath } : inBandRejected(r);
 			} catch (err) {
 				return { outcome: "failed", error: err };
 			}