In file apps/web/src/appSettings.ts around lines 29-31:

Adding `customClaudeModels` as a required field causes `Schema.decodeSync` to throw when decoding existing `localStorage` data that lacks this key. The caught error triggers fallback to `DEFAULT_APP_SETTINGS`, permanently discarding the user's saved configuration. Mark the field optional with a decode-time default instead of using `withConstructorDefault`.

Evidence trail:
apps/web/src/appSettings.ts lines 29-31 (customClaudeModels definition with withConstructorDefault), lines 134-143 (parsePersistedSettings using decodeSync with catch fallback to DEFAULT_APP_SETTINGS). Git diff (MERGE_BASE..REVIEWED_COMMIT) shows customClaudeModels being added. Effect-TS issue #1997 (https://github.com/Effect-TS/effect/issues/1997) confirms withConstructorDefault provides defaults at construction time only, not during decode: "I often find myself needing to provide default values at construction, but not at parsing."

Also found in 1 other location(s):
- apps/web/src/routes/_chat.settings.tsx:65 -- The `getCustomModelsForProvider` function directly returns `settings.customClaudeModels`. Since `customClaudeModels` is a new property added to the schema in this PR, the persisted `settings` object in local storage for existing users will not contain this key. This causes the function to return `undefined`. Consuming code (e.g., `SettingsRouteView` at lines 164 and 398) assumes an array and will crash with a `TypeError` when accessing `.length` or `.includes()` on `undefined`. The accessor should default to an empty array (e.g., `settings.customClaudeModels ?? []`) to handle the schema migration for existing data.

In file apps/server/src/codexAppServerManager.ts around lines 807-820:

In `respondToUserInput`, `context.pendingUserInputs.delete(requestId)` is called before validating `answers` via `toCodexUserInputAnswers`. If conversion throws, the request record is permanently lost but no response reaches the provider, leaving the session corrupted and blocking retries. Move the deletion after successful validation and conversion.

Evidence trail:
apps/server/src/codexAppServerManager.ts lines 807-825 (REVIEWED_COMMIT): `respondToUserInput` method showing delete at line 818, conversion at line 819
apps/server/src/codexAppServerManager.ts lines 358-381 (REVIEWED_COMMIT): `toCodexUserInputAnswer` function that throws Error at line 370, and `toCodexUserInputAnswers` that calls it
Line 818: `context.pendingUserInputs.delete(requestId);`
Line 819: `const codexAnswers = toCodexUserInputAnswers(answers);`
Line 370: `throw new Error("User input answers must be strings or arrays of strings.");`

In file apps/server/src/codexAppServerManager.ts around line 428:

`startSession` overwrites `this.sessions.set(threadId, context)` without checking if a session already exists for that `threadId`. This orphans the previous process (which keeps running) and leaves its `exit` handler active. When the orphaned process later exits, that handler calls `this.sessions.delete(threadId)`, which removes the *new* session from the map. Subsequent calls like `sendTurn` then fail with "Unknown session" because the entry was deleted by the stale handler.

Evidence trail:
apps/server/src/codexAppServerManager.ts: lines 428-471 show `startSession` calls `this.sessions.set(threadId, context)` without checking for existing session; line 943 shows exit handler calls `this.sessions.delete(context.session.threadId)` where `context` is captured in closure; lines 890-893 show `requireSession` throws 'Unknown session' when entry not in map; lines 606-607 show `sendTurn` uses `requireSession`.

Also found in 1 other location(s):
- apps/server/src/provider/Layers/CodexAdapter.ts:1262 -- The `nativeEventLogger` created when `options.nativeEventLogPath` is provided is never closed. While `manager` is wrapped in `Effect.acquireRelease` for cleanup, `nativeEventLogger` is instantiated separately and its `close()` method is never called. This causes file handles opened by the logger to leak every time the `CodexAdapter` layer is released (e.g., during configuration reloads or tests).

In file apps/web/src/components/Icons.tsx around lines 329-341:

The `OpenCodeIcon` component uses hardcoded `fill` attributes (`#211E1E` and `#BCBBBB`) on its SVG paths. In dark mode, the `#211E1E` dark grey fill renders the icon nearly invisible due to low contrast against dark backgrounds. Unlike `GitHubIcon` and `OpenAI`, which use `currentColor` to inherit the surrounding text color, this icon fails to adapt to the theme.

Evidence trail:
apps/web/src/components/Icons.tsx lines 329-342 (OpenCodeIcon with hardcoded fills #211E1E and #BCBBBB), lines 5-15 (GitHubIcon with fill="currentColor" at line 12), lines 146-150 (OpenAI with fill="currentColor" at line 147). Verified at commit REVIEWED_COMMIT.

In file apps/server/src/provider/Layers/ClaudeAdapter.ts around lines 2502-2511:

When `nativeEventLogPath` is provided, `makeClaudeAdapter` creates an `EventNdjsonLogger` internally at line 644, but the finalizer (lines 2502-2511) never calls `nativeEventLogger.close()`. This leaves file handles held by the logger's thread writers open until process exit. Consider calling `nativeEventLogger.close()` in the finalizer when the logger was created internally.

Evidence trail:
- apps/server/src/provider/Layers/ClaudeAdapter.ts lines 641-646 (REVIEWED_COMMIT): Shows `nativeEventLogger` is created internally via `makeEventNdjsonLogger` when `nativeEventLogPath` is provided
- apps/server/src/provider/Layers/ClaudeAdapter.ts lines 2502-2511 (REVIEWED_COMMIT): Finalizer only stops sessions and shuts down queue, no `nativeEventLogger.close()` call
- apps/server/src/provider/Layers/EventNdjsonLogger.ts lines 25-29, 188-195 (REVIEWED_COMMIT): Shows `EventNdjsonLogger` interface has a `close()` method that closes all thread writers
- git_grep for `nativeEventLogger.close` in ClaudeAdapter.ts: No results, confirming `close()` is never called

In file apps/server/src/orchestration/Layers/ProviderCommandReactor.ts around line 595:

The `if (!isUnknownPendingApprovalRequestError(cause)) return;` statement at line 596 is dead code — there are no subsequent statements in the generator, so the return has no effect and the generator completes with `void` either way. This appears to be incomplete logic where additional handling was intended for the unknown pending approval request case.

Evidence trail:
apps/server/src/orchestration/Layers/ProviderCommandReactor.ts lines 585-598 at REVIEWED_COMMIT - The generator function contains `if (!isUnknownPendingApprovalRequestError(cause)) return;` at line 596, followed immediately by the closing of the generator (`}),`). No statements follow the if statement, making the return statement have no observable effect.

In file apps/server/src/provider/Layers/ProviderService.ts around line 247:

In `recoverSessionForThread`, `upsertSessionBinding` is called at line 247 without passing `persistedModelOptions` and `persistedProviderOptions`, even though these values were extracted and used to start the session. After recovery, the runtime payload drops these options, so subsequent operations that read the persisted binding won't see the original model/provider configuration.

Evidence trail:
apps/server/src/provider/Layers/ProviderService.ts lines 229-230 (extraction of persistedModelOptions and persistedProviderOptions), lines 234-235 (passing them to startSession), line 247 (upsertSessionBinding called without extra parameter), lines 162-177 (upsertSessionBinding signature showing optional extra parameter), lines 88-99 (toRuntimePayloadFromSession showing options only included if extra is provided), lines 308-311 (startSession correctly passing options to upsertSessionBinding)

In file apps/server/src/provider/Layers/ClaudeAdapter.ts around line 1365:

In the `content_block_stop` handler (line 1354), when the stopped block corresponds to a tool (not an assistant text block), the tool is fetched from `context.inFlightTools` at line 1365 but execution silently falls through without emitting any event. This means the final accumulated tool input from `input_json_delta` streaming is never published as an `item.updated` event when the content block finishes — the UI will show stale/partial tool input until the tool result message arrives later. The `input_json_delta` handler only emits updates when the fingerprint changes, so any final delta that didn't alter the fingerprint is lost. Add an `item.updated` emission (following the same pattern as the `input_json_delta` handler at lines 1256–1281) after line 1368 to publish the tool's final input state.

Evidence trail:
apps/server/src/provider/Layers/ClaudeAdapter.ts lines 1354-1369: `content_block_stop` handler shows the tool is fetched at line 1365 (`const tool = context.inFlightTools.get(index);`), then lines 1366-1368 only check `if (!tool) { return; }` with no code to handle when tool exists - the handler ends at line 1369.

apps/server/src/provider/Layers/ClaudeAdapter.ts lines 1242-1249: `input_json_delta` handler shows the fingerprint check that prevents emission when fingerprint is unchanged: `if (!parsedInput || !nextFingerprint || tool.lastEmittedInputFingerprint === nextFingerprint) { return; }`

apps/server/src/provider/Layers/ClaudeAdapter.ts lines 1256-1281: Shows the `item.updated` event emission pattern in `input_json_delta` handler that is missing from the `content_block_stop` tool handling.

In file apps/web/src/components/ChatView.tsx around line 2339:

When sending only images, the optimistic user message displays the internal `IMAGE_ONLY_BOOTSTRAP_PROMPT` text (`"[User attached one or more images...]"`) in the chat bubble instead of showing only the attached images. This happens because `onSend` sets `text: outgoingMessageText` on line 2344, where `outgoingMessageText` falls back to the bootstrap prompt when the user provided no text. Previously the optimistic message used an empty `text` field for image-only sends, which correctly hid the internal instruction from users. Consider using an empty string for the optimistic message's `text` field when the original `trimmed` prompt was empty, keeping only the attachments visible.

Evidence trail:
apps/web/src/components/ChatView.tsx lines 172-173: IMAGE_ONLY_BOOTSTRAP_PROMPT definition; lines 2319-2320: outgoingMessageText uses `trimmed || IMAGE_ONLY_BOOTSTRAP_PROMPT` fallback; line 2344: optimistic message sets `text: outgoingMessageText`

In file apps/web/src/components/ChatView.tsx around line 181:

`formatOutgoingPrompt` checks `params.effort === "ultrathink"` to apply the prompt prefix, but `selectedPromptEffort` is computed from `selectedClaudeBaseEffort` which explicitly excludes `"ultrathink"`. This branch is unreachable — the ultrathink prompt prefix is never applied during send, only when `ClaudeTraitsMenuContent` directly edits the prompt. Consider removing the dead branch or ensuring the prefix is applied consistently when ultrathink is active.

Evidence trail:
apps/web/src/components/ChatView.tsx:181-189 (formatOutgoingPrompt checks params.effort === "ultrathink"), apps/web/src/components/ChatView.tsx:570 (selectedPromptEffort = selectedCodexEffort ?? selectedClaudeBaseEffort), apps/web/src/components/ChatView.tsx:539-543 (selectedCodexEffort is null when provider is claudeAgent), apps/web/src/components/ChatView.tsx:548-565 (selectedClaudeBaseEffort explicitly excludes "ultrathink" at line 557: draftEffort !== "ultrathink"), apps/web/src/components/ChatView.tsx:2317-2320,2723-2726,2839-2842 (all calls pass selectedPromptEffort as effort)

In file apps/server/src/provider/Layers/ClaudeAdapter.ts around lines 2511-2519:

In `sendTurn`, the code at lines 2515-2519 calls `completeTurn(context, "completed")` whenever `context.turnState` exists, without checking whether the turn is a synthetic background turn or an active user-initiated turn. This causes any ongoing user turn to be incorrectly marked as completed when the user sends a new message, even if the previous turn was still processing. The comment claims this only closes "stale synthetic turns," but the condition `if (context.turnState)` matches all turns. Consider adding a flag to distinguish synthetic turns from user turns, or checking that the turn is actually synthetic before auto-completing it.

Evidence trail:
apps/server/src/provider/Layers/ClaudeAdapter.ts lines 2515-2518 (REVIEWED_COMMIT): shows `if (context.turnState)` condition with comment claiming it's for synthetic turns only.
apps/server/src/provider/Layers/ClaudeAdapter.ts lines 85-93 (REVIEWED_COMMIT): `ClaudeTurnState` interface has no flag to distinguish synthetic vs user turns.
apps/server/src/provider/Layers/ClaudeAdapter.ts lines 1592-1606 (REVIEWED_COMMIT): synthetic turn creation - same ClaudeTurnState structure as user turns.
apps/server/src/provider/Layers/ClaudeAdapter.ts lines 2545-2554 (REVIEWED_COMMIT): user turn creation - identical ClaudeTurnState structure with no distinguishing flag.
apps/server/src/provider/Layers/ClaudeAdapter.ts lines 2043-2053 (REVIEWED_COMMIT): `requireSession` only checks session existence, not status, so `sendTurn` can be called while a turn is active.