Severity M. 2026-09-09, during the Codex hooks continuation.
Parked in docs/kit-friction-log.md on 2026-09-09 because the operator had gone to sleep before wrap-up and no exact payload could be approved. Filed now on the operator's go-ahead. Searched the tracker first on "codex desktop hooks", "UI mode window identify" and "effective config task cwd"; the only hit was #301, which is about PR follow-through having no Codex counterpart and is unrelated.
Reproduction
While establishing the desktop client's hook behaviour for the continuation, guidance repeatedly asked the operator to identify or switch windows from their appearance. The supplied Codex view did not identify its own effective configuration. The task that was actually recorded ran under the ordinary profile with hooks explicitly enabled. A private profile's saved UI mode was then overinterpreted as the explanation for which window the operator was looking at.
Mechanism
App identity, UI mode, and task/config identity were treated as interchangeable observations. They are three different things, and only the third determines what the run under test actually did:
- which application binary is in front of you,
- which mode that window is displaying,
- which profile and configuration the task resolved against, and in which cwd.
A window's appearance answers the first two and says nothing about the third. Directing an operator to act on appearance therefore produces steps whose target is unestablished, and any result gets attributed to a configuration nobody confirmed. This is the same failure family as reading an absence as evidence — a check that cannot see the thing it is being asked about, whose output is then treated as though it could.
Why it matters beyond that session
The continuation's value was that every observation was bound to its command, revision and date. This step could not be bound that way at the time, and the record says so. Anything that reaches for a GUI to establish runtime behaviour will meet the same wall, so the remedy belongs in how such observations are set up rather than in that one session.
Proposed direction
Bind the actual task's cwd and configuration before directing another UI step. Establish the target from the task record — the resolved config layers and the cwd the run reports — and only then ask for an interaction. Where a bounded test is needed, prefer the available task API over a window instruction, so the thing under test is named rather than pointed at.
Notes
The continuation's own conclusions are unaffected and were not weakened by this: its desktop result is explicitly scoped to that client and that fixture, and it does not assert every client's default. This issue is about the method that step used, not about what was concluded.
https://claude.ai/code/session_01936YzSmyhWE9xmeHWYGsn1
Severity M. 2026-09-09, during the Codex hooks continuation.
Parked in
docs/kit-friction-log.mdon 2026-09-09 because the operator had gone to sleep before wrap-up and no exact payload could be approved. Filed now on the operator's go-ahead. Searched the tracker first on "codex desktop hooks", "UI mode window identify" and "effective config task cwd"; the only hit was#301, which is about PR follow-through having no Codex counterpart and is unrelated.Reproduction
While establishing the desktop client's hook behaviour for the continuation, guidance repeatedly asked the operator to identify or switch windows from their appearance. The supplied Codex view did not identify its own effective configuration. The task that was actually recorded ran under the ordinary profile with hooks explicitly enabled. A private profile's saved UI mode was then overinterpreted as the explanation for which window the operator was looking at.
Mechanism
App identity, UI mode, and task/config identity were treated as interchangeable observations. They are three different things, and only the third determines what the run under test actually did:
A window's appearance answers the first two and says nothing about the third. Directing an operator to act on appearance therefore produces steps whose target is unestablished, and any result gets attributed to a configuration nobody confirmed. This is the same failure family as reading an absence as evidence — a check that cannot see the thing it is being asked about, whose output is then treated as though it could.
Why it matters beyond that session
The continuation's value was that every observation was bound to its command, revision and date. This step could not be bound that way at the time, and the record says so. Anything that reaches for a GUI to establish runtime behaviour will meet the same wall, so the remedy belongs in how such observations are set up rather than in that one session.
Proposed direction
Bind the actual task's cwd and configuration before directing another UI step. Establish the target from the task record — the resolved config layers and the cwd the run reports — and only then ask for an interaction. Where a bounded test is needed, prefer the available task API over a window instruction, so the thing under test is named rather than pointed at.
Notes
The continuation's own conclusions are unaffected and were not weakened by this: its desktop result is explicitly scoped to that client and that fixture, and it does not assert every client's default. This issue is about the method that step used, not about what was concluded.
https://claude.ai/code/session_01936YzSmyhWE9xmeHWYGsn1