codex-loop AI Terminal（本地 MVP+）

启动方式

1. 终端一：python3 tools/codex_loop_web_relay.py --workspace /home/clashuser/hzh/item_bo/learn-likecc
2. 终端二：cd site && python3 -m http.server 8080
3. 浏览器打开 http://127.0.0.1:8080/topic-codex-loop-console.html

Relay

Workspace

Repo-backed 补充：别把 Session Browser、Operator HUD、Local Desk 混成一层

最近补 Session Stack 时，最容易犯的错不是“功能不够多”，而是把不同参考项目解决的问题揉成同一种控制面。把边界拆开之后，LikeCode 本地 AI Terminal 应该学什么，会更清楚。

所以当前这页更准确的定位不是“又一个 Claude 风格聊天壳”，而是 local operator desk。

• Hermes WebUI / CloudCLI UI 提醒我们要把 session、workspace、入口工位收拢。
• Hermes HUD 提醒我们要把 self-observability、approval queue、runtime cues 抬到第一屏。
• 但本页仍然只服务一个本地 loop workspace：它优先回答 daemon / thread / shell 现在谁接管、谁可写、下一步该处理什么。

这也是为什么 Session Stack 现在更像一个带 guardrails 的 operator summary，而不是完整 session browser，更不是 agent 自我意识看板。

再压一层：把 Session Stack 读成五层控制面契约

如果只把这一块看成“又多了几个状态卡片”，它会继续显得很碎。更稳定的读法，是把它当成一个固定的 operator reading order。

这样切之后，Session Stack 的阅读顺序就更清楚了。

• 先看 Quick Actions，确认入口工位和恢复动作还在不在。
• 再看 Attention Queue，判断现在最热的风险到底落在 relay、thread 还是 shell。
• 再看 Session Identity 与 Desk Assignments，确认“是谁”以及“哪个工位接着它”。
• 最后才下钻到 Shell Roster，处理具体 session 的 runtime 细节。

这套分层对 LikeCode 的意义，不是把一页做得更复杂，而是守住一个约束：同一层只回答同一种 operator 问题。否则一旦 Session Identity、Desk Assignments、Shell Roster 都开始同时回答“当前谁接管了哪个 shell”，这个控制面很快又会退回“信息很多，但没人知道先看哪”的状态。

别把 approval 也揉成一种：它至少有三层边界

如果只盯着 Session Stack 的 ownership 和 reading order，还是会漏掉另一条更硬的 operator 约束：“谁在接管” 和 “谁能放行动作” 不是一回事。参考仓里至少已经能看到三种不同的 approval 边界。

把这三类边界放回 LikeCode，本地 operator desk 更合理的读法应该是：

• Readonly / Writable 先回答 thread 现在有没有写入口，这是 ownership guard，不是动作批准本身。
• Attention Queue 或后续更细的 approval cue，才应该回答“哪个动作正在等你放行”。
• 真正涉及文件或产物改写时，还应该保留 proposal / review 的独立层，而不是因为 thread 已经 writable 就默认可以直接写。

所以更稳的控制面约束不是“所有安全都进一个状态条”，而是把它拆成一条 approval ladder：entry guard -> action approval -> artifact review。这样 Session Stack 负责把人带到正确工位，但不会假装自己已经替 operator 完成了审批。