[Bug]: Phantom remote-closed terminal pane cannot be dismissed (banner mixes EN + "如果这种情况持续存在，请 提交议题.") #9194

Activity

1. harryisfish

   added

   bugSomething isn't workingSomething isn't working

   on Jul 17, 2026
2. harryisfish

   added the

   Bug

   issue type on Jul 17, 2026
3. github-actions

   added

   os:macosIssues affecting macOSIssues affecting macOS

   on Jul 17, 2026
4. AmethystLiang

   assigned

   Jinwoo-H

   and

   OrcaWin

   and unassigned

   Jinwoo-H

   on Jul 17, 2026
5. nwparker

   added

   pending_reproRepro attempted; still pending conclusive reproductionRepro attempted; still pending conclusive reproduction

   on Jul 21, 2026
6. nwparker commented on Jul 21, 2026

   

   nwparker

   on Jul 21, 2026

   Contributor

   More actions

   Investigated on macOS at the code level (HEAD 0e7b0ac). I traced the root cause but could not reproduce it locally — it requires a live Remote Orca Server publishing an inconsistent snapshot, which I can't stand up here, so I'm marking cannot_repro. Sharing the trace in case it helps whoever picks this up.

   What the phantom is: a host-authoritative mirrored web-terminal surface tab that the remote host's session.tabs.list snapshot still lists, but whose handle is already gone. attachHostSessionMirror then emits onError('Remote terminal was closed.') (remote-runtime-pty-transport.ts:282), which TerminalPane shows as the banner (the zh string 如果这种情况持续存在，请… is TerminalErrorToast.tsx / zh.json).

   Why it won't close: the banner's × only dismisses the toast, not the pane (TerminalPane.tsx:2848). Mirrored tabs are host-driven — applyWebSessionTabsSnapshot re-creates them from every snapshot. Closing prunes locally and records a 10s-TTL close intent + a host terminal.close RPC, but the intent only clears when the surface disappears from a snapshot. If the host keeps republishing the zombie surface (your LAN + FRP dual-URL race looks like the trigger), the intent expires after CLOSE_INTENT_TTL_MS and the tab reappears → re-attaches → no handle → banner again.

   Possible fix (host-side is the real cause, but a renderer-side hardening exists): a non-expiring client-side ignore-set for handle-less zombie surfaces, plus fixing the web-runtime-session.ts:434 no-op that skips even the local prune when the environment is inactive. If a maintainer with a Remote Orca Server can reproduce the snapshot inconsistency, that's the place to start. Reopen anytime with a repro on a live server.
7. AmethystLiang

   added

   orca-remote-serverRemote Orca Server / orca serve / paired remote runtimeRemote Orca Server / orca serve / paired remote runtime

   on Jul 22, 2026
8. nwparker

   changed the title [-][Bug]: Phantom "如果这种情况持续存在，请 提交议题." pane cannot be closed[/-] [+][Bug]: Phantom remote-closed terminal pane cannot be dismissed (banner mixes EN + "如果这种情况持续存在，请 提交议题.")[/+] on Jul 24, 2026
9. nwparker

   added 3 commits that reference this issue on Sep 2, 2026

   test(pty,remote): make the fd-leak evidence positive and size the clo…

   ...

   92705e8

   fix(pty): invalidate the descriptor when node-pty gives up the handle (…

   ...

   ccd3b8d

   fix(pty,remote): close the pty master fd leak, and two remote-termina…

   ...

   8197268
10. aicodemate2026 commented on Sep 14, 2026

    

    aicodemate2026

    on Sep 14, 2026

    More actions

    Live repro on 1.4.200 (paired macOS desktop, not dual-URL)

    Still happening on Orca 1.4.200 (darwin arm64). This matches the phantom pane + bilingual banner in the original report. Adding a live Remote Orca Server / paired-runtime reproduction, which the July investigation asked for.

    Setup

    • Client: macOS Orca 1.4.200, paired environment over a private LAN WebSocket (:6768)
    • Remote: second Mac mini, same Orca 1.4.200 desktop app (not headless orca serve)
    • Remote process stayed alive from a Sunday login (PID unchanged) while the workspace window was closed
    • orca status --environment "<paired>" --json while the banner was showing:

    {
      "app": { "running": false, "pid": null, "desktopWindowStatus": "openable" },
      "runtime": {
        "state": "graph_not_ready",
        "reachable": true,
        "connectionState": "workspace-window-closed"
      },
      "graph": { "state": "unavailable" }
    }

    • orca terminal list --environment "<paired>" --json returned totalCount: 0
    • Client UI still kept 5 mirrored web-terminal-* panes and showed:

    Remote terminal was closed. 如果这种情况持续存在，请 提交议题.

    Client log loop (does not stop)

    terminal_pane_recovery_remount with reason: "spawn-left-pane-unbound" repeats about every 15–16s for the same five tab ids, for example:

    • web-terminal-c40a873a-53ae-4730-83be-e9ffc16b0b06
    • web-terminal-6718dc41-895a-4ef0-bd88-ecbaa76c1618
    • web-terminal-f2b3c493-adb2-437e-9ddf-99a9001f9cf7
    • web-terminal-d6fed080-ca88-452f-8f35-389da360f3a3
    • web-terminal-9d561773-832a-4259-b967-66e1583c2c76

    This was still firing after the remote window was reopened.

    Reopening the remote window does not dismiss the panes

    On the remote Mac we ran reopen/activate on Orca. After that:

    • remote desktopWindowStatus became available
    • runtime.state / graph.state became ready
    • connectionState became connected
    • terminal list on both client (via --environment) and the remote host still returned 0 live terminals
    • the five web-terminal-* remounts continued (spawn-left-pane-unbound)

    So this is not only “window closed → Ready badge is a lie” (that part is now labelled). The client keeps host-mirrored surfaces whose PTY handles are gone, cannot close them from terminal list (they are not in the live inventory), and the banner’s × does not remove the pane — same as the July analysis.

    Extra detail vs original report

    Original report used LAN + FRP dual URLs. This repro used a single Thunderbolt LAN WebSocket and a desktop remote (window closed, daemon still serving RPC). Trigger appears to be: remote workspace window closed while the client kept the paired environment selected, then the host snapshot kept republishing zombie mirrored tabs.

    Happy to attach more main.trace.ndjson breadcrumbs if useful. No pairing tokens or credentials in this comment.
11. LesleyMurfin commented on Sep 17, 2026

    

    LesleyMurfin

    on Sep 17, 2026

    Contributor

    More actions

    Cross-referencing for context: PR #21277 addresses related tab lifecycle resurrection behavior. In PR #21277, we explicitly preserved the propagation of tab_not_found errors from the host so that makeWebSessionCloseIntentDurable in the renderer lifecycle remains engaged. This ensures the durable close tombstone protection introduced for #9194 is not bypassed and phantom/zombie tabs are prevented from resurrecting.
12. enrick-dev

    added a commit that references this issue on Oct 15, 2026

    fix(pty,remote): close the pty master fd leak, and two remote-termina…

    ...

    5c4ea41
13. nwparker commented on Oct 26, 2026

    

    nwparker

    on Oct 26, 2026

    Contributor

    More actions

    @harryisfish @aicodemate2026 thanks for the repro. The 1.4.200 report came just before #21277 (v1.4.206), which keeps a closed tab's close intent durable, so a host snapshot that still lists the dead tab can't bring the phantom pane back. That builds on #17914 (v1.4.197).

    Could you check on v1.4.241 on both Macs? We'll close this in two weeks if we don't hear back.