Tmux 和 Claude Code：会话、Send-Keys，以及天花板

整体主题：tmux + AI 代理，以及“agent multiplexers”的兴起

• 许多评论者会在 tmux（或类似工具）中运行 Claude Code 和其他代理，以获得持久性、远程访问和编排能力。
• 越来越明显的趋势是出现专门面向“agent”的 multiplexers 和 IDE，它们建立在 tmux 之上，或直接取代 tmux。

tmux 的替代方案与比较观点

• 文中提到一些终端/代理工具，被认为在多代理工作流中“开箱即用”地更好：herdr、Orca IDE、CMUX、Zellij、workmux、shpool、zmx、自定义守护进程，以及各种量身定制的工具。
• 有些人觉得 herdr 为代理提供了比 tmux 更完整的功能集合，且可视化更友好；也有人报告它不稳定（偶尔崩溃），并担心 VC 资助项目会“卷款跑路”。
• 有些人认为 Orca 在易用性上是一次巨大飞跃，也有人觉得它过于臃肿、功能过头。
• Zellij 因为更“自带一切”、更用户友好，而被视为比 tmux 更好的替代品。

自定义工具与实验

• 许多人自己写了 harness 或 multiplexers 来管理代理，通常作为守护进程，并配有 Web 或原生前端、持久会话、自动休眠、轻客户端、移动端访问，以及代理之间的通信。
• 一些开源工具被贴出链接（例如 tmux 桥接、会话守护进程、GUI）；其他工具目前是闭源或只做了部分文档说明，当安装脚本去获取不透明二进制文件时，会引发批评。
• 一个反复出现的目标是：在重启后恢复完整工作流，跟踪哪些会话需要关注，并在不丢失上下文的情况下编排大量代理。

架构争论：守护进程还是终端 multiplexers

• 一派认为代理应该是无头守护进程、可附加客户端；使用 tmux + 终端抓取被视为一种架构反模式。
• 另一派反驳说，tmux 实际上已经有效地提供了这种分离/重新附加的守护进程模型，尤其是在 SSH 场景下。
• claude agents 被指出自带持久化守护进程，在某些设置中减少了对 tmux 的需求。

安全、沙箱与信任

• 一些用户通过硬件支持的 SSH 密钥、Secure Enclave、硬件令牌、沙箱工具、加密密钥，以及带有显式审批的基础设施即代码，来限制代理的权限。
• 另一些人警告说，给予 Claude 直接 SSH/服务器访问权限会引入一个常驻后门，而且 prompt injection 仍然没有解决。
• 人们对专门的沙箱很感兴趣，希望它们能把代理彼此隔离，并与主机文件系统隔离；但实现细节多种多样，有时也不够清晰。

UX、人体工学与认知负担

• tmux 被广泛称赞为 CLI 用户的基础技能，尤其是在远程机器上。
• 另一些人则更喜欢 GUI 终端、VS Code/Cursor，或 ChatGPT/Claude 桌面应用，以避免 tmux 的键绑定和配置开销。
• 管理过多并发会话和窗格被描述为在认知上很消耗；有几位用户表示他们希望把活跃会话数量控制得非常少。
• 链接文章的网站设计也遭到批评，认为它难以阅读（文本栏太窄、CSS 很奇怪），有人建议用阅读模式作为替代办法。