🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

Codex review: needs maintainer review before merge. Reviewed August 29, 2026, 3:16 PM ET / 19:16 UTC.

ClawSweeper review

What this changes

This PR prevents an old Talk-overlay fade-out completion from hiding a panel that was presented again during the fade.

Merge readiness

⚠️ Ready for maintainer review - 3 items remain

The patch is a correct, bounded repair for a current macOS Talk-overlay race; it should remain open pending a fresh successful exact-head macOS CI run.

Priority: P2
Reviewed head: 0075bc361e4ed2364cf6bd9a89ccd2501a99545e

Review scores

Verification

How this fits together

Talk Mode drives an AppKit overlay panel when the operator enables or disables Talk. The overlay controller converts those requests into panel animations, whose asynchronous completion must respect the latest visibility intent.

flowchart LR
A[Talk Mode toggle] --> B[Talk mode controller]
B --> C[Talk overlay controller]
C --> D[Present or dismiss animation]
D --> E[Current transition check]
E --> F[Visible Talk panel]

Before merge

• Resolve merge risk (P1) - macos-swift was cancelled on this exact head, so the required macOS CI gate has not yet demonstrated a green result even though the focused contributor evidence is positive.
• Resolve merge risk (P1) - The bug fix is net +35 production lines; the transition identity is justified by asynchronous completion ownership, but it should remain the sole local mechanism for this panel.
• Complete next step (P2) - A maintainer needs to restore the cancelled exact-head macOS CI gate; no focused repair action is indicated by this review.

thanks, the ask was fair. the flag i was asserting is not what an operator sees, so it did not settle the question.

pushed 3c97b53c, which asserts the panel itself. window is readable now, setter still file private, and the test checks alphaValue and isVisible on the real NSPanel after the fade that present interrupted has finished.

on the base, with only present -> dismiss -> present and then waiting out the 160 ms:

✘ "the panel itself is left visible and opaque after the interrupted fade"
    Expectation failed: (panel?.alphaValue → 0.0) == (1 → 1.0)
    Expectation failed: (panel?.isVisible → false) == true
    Expectation failed: (controller.model.isVisible → false) == true

so the panel is fully transparent and ordered out while Talk is still enabled. that is the reported symptom measured on the object the dismissal animation was driving, not on the flag. on this branch all four pass.

i have not attached a recording. this is a headless assertion of the same two properties a screenshot would be showing, alphaValue and isVisible, and it is exact and re-runnable where a screenshot is neither. if you would still rather have the video i can build the app and capture Talk being re-enabled mid dismissal, just say so and i will add it rather than assume this substitutes.

on the rank-up note about inlining evaluateDismissal, i kept it deliberately. VoiceWakeOverlayController.evaluateToken is the same shape, a one-use ownership decision pulled out so it can be asserted directly, and VoiceWakeOverlayControllerTests tests it that way. happy to inline it if you would rather not carry the precedent twice, the interrupted-fade tests do not depend on it being separate.

proof attached, and one limitation stated up front so you can judge whether it clears the gate.

i cannot run screencapture here. it returns could not create image from display, this machine has no display access, so a recording of the running app is not something i can produce. rather than leave it at test output i rendered the surface instead.

TalkOverlayRenderProbe (2d09b0d8) drives the real TalkOverlayController through present, dismiss, present, waits past the 160 ms fade, then renders the real overlay view and composites it at the panel's own alphaValue, drawing nothing when the panel is ordered out. that composite is what reaches the screen.

	after present	after the interrupted dismissal
base
this branch

the second base frame is empty. Talk is still enabled, and the panel is transparent and ordered out:

base    PROBE 1-presented:                    visible=true  alpha=1.0
base    PROBE 2-after-interrupted-dismissal:  visible=false alpha=0.0
branch  PROBE 1-presented:                    visible=true  alpha=1.0
branch  PROBE 2-after-interrupted-dismissal:  visible=true  alpha=1.0

the first frame is byte identical across base and branch, 173,915 bytes both, so the ordinary present is untouched. the second is 107,299 bytes on base against 174,156 on the branch, and that difference is the orb.

the probe is in the branch and does nothing unless OPENCLAW_TALK_PROBE_DIR is set, so ci is unaffected and you can reproduce both columns:

OPENCLAW_TALK_PROBE_DIR=/tmp/shots swift test --filter TalkOverlayRenderProbe

if this still does not meet the native proof gate, say so and i will ask the machine owner to run the app and capture Talk being re-enabled mid dismissal. i would rather be told it is insufficient than have you infer i tried to pass a rendered composite off as a screenshot, which is why the method is spelled out above.

understood, and i have run out of what i can do about it from here, so rather than push a fifth revision at the same gate let me say where it stands and ask a maintainer to decide.

what is blocking is not the patch. both re-reviews put patch quality at 🐚 platinum hermit and confirmed the defect on current main, the repair, the caller boundary and the sibling precedent. it is the proof tier, and the remaining ask is a capture from the running app.

i cannot produce one. screencapture on this machine returns could not create image from display, there is no display access, and that is not something i can work around from inside a test process. i took it as far as rendering the real view composited at the panel's real alpha, which the review credited as visibly distinguishing base from branch, and that moved the rating but not the gate.

so the honest position: this needs someone with a running OpenClaw install to open Talk, dismiss it and re-enable inside the fade, and record it. i am happy for that to be a maintainer, or i can ask the owner of this machine to set the app up and capture it, which will take a little longer.

the question i actually want answered: is a native capture required from outside contributors who do not have the app running, or is it a gate you apply to work that changes UI you can already exercise? if it is required regardless, say so and i will get the recording rather than keep substituting for it. if the evidence already here is enough for a human reviewer, this is ready.

not asking anyone to lower a bar. asking which bar applies, so i stop guessing at it.

screen recording is granted on this machine now, so here is the capture you asked for. real panel, on screen, photographed with screencapture.

	after present	after the interrupted dismissal
base
this branch

the second base frame is the empty one. Talk is still enabled and its only visible surface is gone.

base    SHOT 1-presented:                    windowNumber=97949 visible=true  alpha=1.0
base    SHOT 2-after-interrupted-dismissal:  windowNumber=97949 visible=false alpha=0.0
branch  SHOT 1-presented:                    windowNumber=97943 visible=true  alpha=1.0
branch  SHOT 2-after-interrupted-dismissal:  windowNumber=97943 visible=true  alpha=1.0

on scope, since this is a real display. the capture is screencapture -x -o -l<windowNumber>, restricted to the Talk panel's own window. all four frames are 880x880, which is the 440pt panel at 2x. a full grab on this machine is 2704x1756. nothing else that was on screen is in these images, and that was deliberate rather than incidental.

TalkOverlayScreenshotProbe is in the branch at 0075bc36 and does nothing unless OPENCLAW_TALK_SHOT_DIR is set, so ci is unaffected:

OPENCLAW_TALK_SHOT_DIR=/tmp/shots swift test --filter TalkOverlayScreenshotProbe

it drives TalkOverlayController rather than launching the menu bar app, so if the gate specifically means the shipped app with Talk mode running end to end, this still is not that and i would rather you tell me than assume it passes. what it is, is the real panel in the real window server, photographed, showing the reported sequence.

The canonical repair landed in #135731 as 1bf5fb68d389, and I verified that commit is on main. Closing this overlapping proposal as superseded, with Huzaifa Iftikhar's contributor credit preserved in the landed commit.

The Talk controller now records visibility intent immediately and gives each transition its own token. An old dismissal completion cannot hide a newer presentation. The shared animation factory remains unchanged, and removing the redundant nested task keeps the repair at net +1 production line, versus +35 in the original proposal.

The signed synthetic AppKit fixture fails all three rapid-reopen checks when only the token guard is removed; the repaired controller passes all three reopen and all three normal-dismiss checks. Source hashes bind that pre-commit execution to the final committed inputs. The synchronous regression and final-head CI, including Swift tests and the release build, pass. The opt-in AppKit proof is timed native coverage, not a full operator microphone session; details and earlier CI failures are retained in #135731.