MacOSX Native tmux AI Agent Integration

Mac 本機同時開 4 個 Terminal，要不要導入 tmux？

目前的工作畫面是同時開四個 Terminal：

• 1 個開 Codex 寫專案A
• 第 2 個開 Claude code 整理需求與測試紀錄, 隨時用來查詢；
• 第 3 個開 Codex 修改專案B
• 最後一個是偶爾要跑 git、安裝、sass、log、測試指令。

這種用法已經不是傳統「一個 terminal 寫程式、另一個 terminal 跑測試」而已，而是接近 2026 年常被討論的 terminal-first AI coding workflow：多個 AI agent 同時處理不同工作，使用者在旁邊看狀態、問需求、驗 diff、跑測試。

問題是：這種情境要不要導入 tmux？

整理 Mac 使用者的文章與討論後，結論不是「一定要把所有 Terminal 全部搬進 tmux」。更合理的判斷是：macOS 原生視窗、Mission Control、Terminal／iTerm2／Ghostty 繼續負責外層切換；tmux 先用在持久 session、遠端 SSH、長時間指令，以及必要時保留工作現場。

同時也要保留另一個不同論點：2026 年並行 AI agent 興起後，tmux + git worktree + TUI／dashboard 的組合確實變得更有吸引力。如果同一個 repo 裡同時跑多個 agent，問題就不只是「怎麼切視窗」，而是「怎麼隔離任務、保留 session、知道哪個 agent 卡住」。

所以這篇不是要判斷 tmux 必用或無用，而是整理兩派說法，最後套回「本機同時開四個 Terminal 跑 Codex、Claude Code、ops shell」的工作情境。

---

一、Mac 本機不用 tmux 也足夠的一派

第一派意見很明確：如果只是本機開發，現代 Mac terminal app 的分頁、分割視窗、Cmd+數字、Mission Control 已經能涵蓋多數需求。

1. 本機 panes / tabs 已經夠用，tmux 留給遠端

〈iTerm vs cmux vs tmux: Why That Question Is Backwards〉的作者使用 M2 MacBook Air，日常靠 iTerm2 + zsh，明確區分「本機不用 tmux」與「SSH 到 server 才開 tmux」。作者的判斷是：本機 iTerm2 / Ghostty 的 panes 與 tabs 已經足夠；tmux 真正的強項，是遠端 session 與斷線後仍能接回原狀。¹

這個論點對「四個 Terminal 都在 Mac 本機」的情境很有參考價值。若只是把四個 Terminal 全部塞進同一個 tmux session，再靠 prefix 切換，反而可能失去原本同時看狀態的優點。

2. Cmd+數字 切換分頁很快，本機不一定需要持久 session

〈My Tmux Workflow〉也有類似分工：作者在 server 工作時用 tmux，但在 Mac 上只用 iTerm2；用 Cmd+數字 切換分頁已經很快，本機較少需要持久 session。²

DEV Community 的討論也接近這個觀點：Cmd+數字 一鍵切換、原生、接近即時，還能把分頁拉出來併排或併到別的視窗；本機用 tmux 不一定有額外好處，遠端主機才是 tmux 更明顯的使用場景。³

3. 本機視窗管理交給 iTerm2 或 macOS，tmux 留給遠端

SuperUser 上有人把問題問成「有 tiling window manager 後，tmux 是否變多餘？」回答者的實務分工是：本機筆電用 iTerm2 的 split panes 與多視窗管理，tmux 留給遠端主機上的持久 terminal sessions。⁴

這種看法的核心不是反對 tmux，而是把邊界切清楚：本機畫面切換交給 Mac；需要斷線後接回來的工作交給 tmux。

4. 顏色、字型、TUI 畫面可能讓本機 tmux 變麻煩

HN 上也有人提到反面經驗：因為 vim、tmux、iTerm2 之間的顏色與字型問題，放棄本機 tmux；他認為本機 tmux 帶來的主要好處只是撐過軟體更新與少量 session persistence，但渲染問題反而造成摩擦。⁵

這點在 Claude Code / Codex 這種重量級 TUI 上更重要。AI TUI 可能有顏色、滑鼠、scrollback、特殊輸出等問題；如果只是本機使用，直接放在原生 Terminal 視窗裡，反而比較少變數。

5. Ghostty 使用者也有「少用遠端，所以不需要 tmux」的說法

Reddit 上也有相近的小型討論：Ghostty 使用者問「有了 Ghostty，還要不要繼續用 tmux？」發文者的理由是自己很少使用遠端 server，所以不太需要持久 session，而且覺得 Ghostty 原生 multiplexing 比較輕快。⁶

Quora 上的回答也把適用情境切得很清楚：單機、短工作、重度 GUI 使用時，原生分割更簡單也更快；如果不遠端、不需要持久化、不在終端機內協作，內建分割／分頁就足夠。⁷

這一派的共同點可以整理成三句話：

• 本機畫面分割、分頁、視窗切換：Mac terminal app 與 macOS 已經很好用。
• 遠端 session、長時間工作、關掉視窗後回復現場：tmux 才是主角。
• 如果 AI TUI 對顏色、滑鼠、特殊畫面輸出很敏感，本機直接跑在原生視窗裡反而比較少問題。

---

二、Mac 原生切換功能搭配 tmux 的一派

第二派不是「不用 tmux」，而是「不要讓 tmux 取代 macOS」。他們把 macOS 的視窗、Spaces、Mission Control 或 Ghostty／iTerm2 tabs 當外層工作區；tmux 則當內層 session 保存與遠端續接工具。

1. Ghostty tabs 當 workspace，tmux session 管狀態

Zenn 的〈Instantly Switch Development Workspaces with Ghostty Tabs and tmux〉很接近這種架構：作者用 Ghostty tabs 當 workspace，再用 tmux session 管每個 tab 裡面的工作區。文章把它整理成三層：Ghostty tabs 管畫面區塊，tmux sessions 管 session，shell hooks / scripts 負責切換。⁸

這種架構可以翻成：每個原生 Terminal 視窗或分頁仍然保留，但裡面各自 attach 到一個 tmux session。tmux 不負責取代視窗排列，而是負責「這個工作狀態可以接回來」。

2. Mission Control 與 tmux 可以分工

Nicholas Clooney 的〈My Super Powered Tmux〉則把 Mission Control 與 tmux 結合：Mac 上 Mission Control 讓每個 desktop 有自己的 grouped session，作者可以把不同 focus 分配到不同桌面。這代表 Mission Control 沒有被 tmux 取代，而是與 tmux 分工。⁹

這個觀點和第一派不同。第一派說「本機原生就夠」；這一派則說「本機原生負責視覺切換，tmux 負責 session 狀態」。兩者並不衝突，差別在於使用者是否需要 session 保存。

3. Aerospace / tiling window manager 管外層，tmux 管終端機內部

〈macOS workflow 2025〉的作者身為網頁開發者，不可能只活在終端機裡，所以把視窗管理交給 Aerospace 這類 tiling window manager，終端機內再交給 tmux。¹⁰

這個分工適合多專案、多工具並行的工作方式：專案 A、需求查詢、專案 B、ops shell，外層可以用 macOS 視覺空間安排；tmux 不必變成整個桌面的主控者。

4. iTerm2 官方 tmux integration 代表另一種併用形式

iTerm2 官方的 tmux integration 也代表這種方向：iTerm2 讓 tmux windows 看起來像原生 iTerm2 windows 或 tabs；如果 iTerm2 結束、SSH 斷線，tmux 仍在遠端跑，之後 tmux -CC attach 可以把 iTerm2 視窗回復到之前狀態。¹¹

這是比較進階的做法：底層是 tmux，外層仍然維持 Mac terminal app 的操作感。它不是「純 tmux」，而是把 tmux 的持久 session 能力接到 iTerm2 的原生介面。

5. SSH + tmux 對 Mac 筆電特別有價值

SuperUser 另一則問答提到用 autossh + tmux 讓 SSH 掛掉後可以接回 session。這對 Mac 筆電特別有意義：闔蓋、Wi-Fi 中斷、VPN 重連後，遠端 tmux session 仍然在。¹²

〈iTerm2 & tmux & ssh〉也採取同樣思路：作者想養成遠端 SSH session 都自動用 tmux 的習慣，避免網路中斷時正在跑的工作消失。¹³

如果公司 Linux 有額外 Claude quota，即使 quota 不多，也很適合拿來跑需求查詢、一次性 review、長時間整理。只要遠端 Claude 開在 tmux 裡，Mac 闔蓋或 SSH 斷線後，Linux session 還會留著。

---

三、2026 的轉折：並行 AI agent 讓 tmux + worktree 變得更有吸引力

到這裡為止，第一派和第二派都可以成立：

• 純本機、不遠端、單線作業：原生視窗就夠。
• 有遠端、長時間指令、需要保留現場：tmux 很有價值。

但 2026 年多了一個變因：並行 AI agent。

Claude 文章裡比較強調這一點：當 feature A 跑一隻 agent、feature B 跑另一隻、第三隻負責 code review，這跟過去「編輯 → 測試 → commit」不是同一種工作型態。在這種情況下，純原生視窗會開始不夠，因為需要的不只是視窗分割，而是：

• session 持久化：闔蓋、SSH 斷線，agent 還在背景跑。
• process 隔離：每隻 agent 各自獨立，互不干擾。
• 任務隔離：不同 agent 不要在同一個 working tree 互相踩檔案。
• 狀態監看：知道哪隻完成、哪隻卡在等輸入、哪隻出錯。

Raine Virta 的 2026 文章就把 Cmd+1-9、tmux session、git worktree 串在一起，讓每個專案或每個 AI 任務有自己的 session 和工作目錄。¹⁴

這裡要保留兩個不同判斷：

• 較保守的判斷：如果專案 A、需求文件、專案 B 本來就分在不同目錄，不需要為了流行立刻導入複雜 worktree。tmux 先用在 ops 與 Linux，AI TUI 逐格測就好。
• 較積極的判斷：如果以後同一個 repo 同時跑兩個 Codex 任務，例如一個修頁面、一個修匯出 bug，worktree 就會變得很有用。因為它解決的不是視窗問題，而是「同一個 repo 內多條修改線互相踩到」的問題。

也就是說，2026 年的轉折不是「tmux 取代 macOS」，而是：

macOS 管外層視覺工作區，tmux 管 session，git worktree 管同一個 repo 裡的並行任務。

---

四、套回四個 Terminal 的 AI 工作畫面

原始工作畫面可以抽象成四個角色：

Terminal 1：Codex 寫專案 A
Terminal 2：Claude Code 整理需求與測試紀錄，隨時查詢
Terminal 3：Codex 修改專案 B
Terminal 4：git / 安裝 / sass / log / 測試指令

整理這些文章後，較妥當的分工是：

Mac 本機視覺工作區：
仍然使用 macOS 原生視窗、Mission Control、Terminal／iTerm2／Ghostty。

Terminal 4：
先搬進 tmux，因為它常跑 git、sass、mvn test、tail log，最適合用持久 session。

Linux Claude：
如果 Claude Code 改走公司 Linux，就一定用 tmux，因為 SSH 斷線或 Mac 闔蓋時，Linux session 還要留著。

Mac 本機 Claude / Codex：
先不要急著搬進 tmux；等到真的需要保留現場，再讓每個 Terminal 各自包一個 tmux session。

最小可行版

Terminal 4 先導入 tmux：

cd "$HOME/Library/CloudStorage/Dropbox/ntnu/workspace/AttendApply"
tmux new -A -s attend-ops

Claude Code 若改走公司 Linux：

ssh 公司Linux
cd ~/workspace/AttendApply_需求
tmux new -A -s attend-docs
claude

如果之後確認 Claude Code / Codex 在 tmux 裡顏色、按鍵、捲動都沒問題，再逐格導入：

# 專案 B / Codex
cd "$HOME/Library/CloudStorage/Dropbox/ntnu/workspace/AttendApply"
tmux new -A -s attend-page
codex

# 專案 A / Codex
cd "$HOME/Library/CloudStorage/Dropbox/ntnu/workspace/MavenizeProjects/TsMgr"
tmux new -A -s tsmgr-dev
codex

如果之後導入 worktree

目前不急。但如果同一個 repo 要同時做兩件程式修改，可以變成：

workspace/
├── AttendApply
│   原本主工作目錄
├── AttendApply__record-css
│   給 Codex 處理工作時數登載頁面樣式
├── AttendApply__export-fix
│   給另一個 Codex 處理匯出 bug
└── AttendApply_需求
    給 Claude 查需求與測試紀錄

建立方式例如：

cd "$HOME/Library/CloudStorage/Dropbox/ntnu/workspace"

git -C AttendApply worktree add ../AttendApply__record-css -b ai/record-css
git -C AttendApply worktree add ../AttendApply__export-fix -b ai/export-fix

這樣做的價值不是更會切視窗，而是每個 agent 的 git status 都很乾淨，出錯時也能直接丟掉那條 worktree，不影響原本主工作目錄。

---

五、最後採用的原則

這些文章整理起來，可以收斂成五句話。

第一，不要把 tmux 當成 macOS 視窗管理器的替代品。 既然 Mac 原生視窗已經能同時放多個工作狀態，就不要為了流行而全部塞進一個 tmux 畫面。

第二，把 tmux 放在它最強的位置。 ops shell、遠端 Linux、長時間測試、容易手滑關掉的 session，最適合先導入。

第三，AI TUI 要逐格測。 Claude Code / Codex 這種重量級 TUI 對顏色、捲動、特殊畫面可能比較敏感，所以先不要一次全搬。

第四，要保留並行 AI agent 派的提醒。 如果以後同一個 repo 內同時跑多個 agent，tmux + worktree 會比純原生視窗更有秩序。

第五，worktree 不是現在一定要用，而是等同一個 repo 真的出現兩條以上修改線時再用。 它解決的是任務隔離，不是畫面管理。

因此，目前較妥當的方案是：

macOS 原生視窗 + tmux session 持久化 + Linux 遠端 Claude 續命；等同一個 repo 開始並行多個程式任務，再加入 git worktree。

這個方案保留 Mac 原生視窗的視覺監看優勢，也補上 tmux 最有價值的地方，同時沒有否定 2026 年社群對 multi-agent orchestration 的判斷。

---

參考來源

1. iTerm vs cmux vs tmux: Why That Question Is Backwards ↩︎

2. My Tmux Workflow ↩︎

3. Devs, why do you use terminal tabs over tmux windows? ↩︎

4. Does using a tiling window manager make a terminal multiplexer obsolete? ↩︎

5. Replacing tmux in my dev workflow — Hacker News discussion ↩︎

6. Are you still using tmux with Ghostty? — Reddit ↩︎

7. Why should I use TMUX when I can just split panes in my terminal? ↩︎

8. Instantly Switch Development Workspaces with Ghostty Tabs and tmux ↩︎

9. My Super Powered Tmux - One Session But Multiple ‘Focuses’ ↩︎

10. macOS workflow 2025 — The Life of Sam ↩︎

11. iTerm2 tmux Integration Documentation ↩︎

12. Automatically reconnecting to SSH with iTerm2 and tmux integration ↩︎

13. iTerm2 & tmux & ssh ↩︎

14. My setup, and why tmux workflow is better than ever ↩︎