Pine：CLI Agent ワークフロー向けの native macOS code editor
AI coding agent が強くなるほど、かなり普通の摩擦が目立ってくる。人間は editor で code を見ているのに、agent は terminal で動いている。Claude Code、Codex、Gemini CLI、OpenCode のような tool は command を実行し、file を変更し、approval を待てる。ただし、人間が今どの file を見ているか、Git status のどこが変わったか、LSP diagnostics が消えたか、別 project の agent が permission prompt で止まっているかを、自然に editor と共有してくれるわけではない。
よくある解決策は、IDE、terminal multiplexer、Git UI、notification tool、chat window を横に並べることだ。動くには動く。しかし window switching は増える。さらに微妙なのは、agent の状態と editor 上の実際の code 状態がずれやすいことだ。Terminal は完了と言っているが editor には diagnostics が残っている。ある agent は input 待ちだが、人間は別 workspace で diff を見ている。
今日見るのは batonogov/pine。これは WebView で包んだ AI dashboard ではなく、SwiftUI + AppKit で作られた native macOS code editor だ。README の中心にある考え方ははっきりしている。Agent は terminal に残る。Code は視界に残る。Pine はその二つを同じ workspace に置く。対象は macOS 26+。No Electron runtime を掲げ、built-in terminal、LSP code intelligence、Git context、split panes、project-wide search、Markdown preview、cross-project Agent Inbox を備える。
GitHub repository API、README、LICENSE、Releases、recent commits を 2026-08-13 時点で確認すると、batonogov/pine は 20 stars、0 forks。主要言語は Swift、license は MIT。Repository created time は 2026-03-09 16:00:01 UTC、latest public push は 2026-08-13 09:39:39 UTC、default branch は main。最新 GitHub Release は v2.3.1、published time は 2026-08-12 04:03:04 UTC で、release asset として Pine-2.3.1.dmg がある。Recent commit は a52b384、message は “fix: make descriptor path recovery sanitizer-safe (#1451)”。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | batonogov/pine |
| 位置づけ | CLI-agent workflow 向け native macOS code editor |
| Stars | 20 |
| Forks | 0 |
| 主要言語 | Swift |
| ライセンス | MIT |
| 作成日時 | 2026-03-09 16:00:01 UTC |
| Latest push | 2026-08-13 09:39:39 UTC |
| Default branch | main |
| 最新 GitHub Release | v2.3.1、2026-08-12 04:03:04 UTC |
| キーワード | macOS、SwiftUI、AppKit、code editor、terminal、LSP、Git、Agent Inbox |
Agent を editor に飲み込まない選択
Pine が面白いのは、complete AI IDE を作り直そうとしていないところだ。最近の tool は chat、completion、agent、review、project management を一つの interface に集めがちだ。その方向にも価値はある。ただ、すでに CLI agent に慣れている人にとって、問題は必ずしも「chat panel が足りない」ことではない。Terminal では Claude Code や Codex に login 済みで、自分の shell、environment variables、auth、working directory の習慣がある。
Pine はその現実を残す。Agent は terminal process のままだ。Editor が提供するのは、その terminal を中心にした作業面である。Built-in VT100/xterm terminal は multiple tabs、themes、TUI apps、clickable file links、OSC 8 links、send-to-terminal、pane maximize、global quick-terminal hotkey を持つ。つまり、agent を新しい hosted runtime へ移すのではなく、terminal を editor 内の first-class surface にする。
これは local workflow では大きい。多くの agent の信頼性は、実際の shell で動いていることから来る。Project の toolchain を使え、local Git state を読み、test を走らせ、approval を求められる。Pine はその基盤を置き換えるのではなく、人間側の visibility を補う tool に見える。
Agent Inbox が具体的な入口になっている
README の “New in Pine 2.0” で目立つのは Cross-project Agent Inbox だ。普通の task list に聞こえるかもしれないが、狙っているのは CLI agent のかなり現実的な問題だ。Session は複数 project、複数 terminal tab、複数 branch、複数 worktree に散る。少し席を外して戻ったとき、最初に知りたいのは code completion ではない。どの agent が待っていて、どれが終わり、どれを元の live session に戻って見るべきかだ。
Pine は durable tasks、exact live session routing、isolated worktrees、task recovery、evidence-based completion briefs、privacy-bounded notifications を agent-aware workflow としてまとめている。ここでの keyword は「もっと自動で code を書く」ではなく、agent session の lifecycle を見えるようにすることだ。複数 project を抱える developer には、もう一つの chat entry よりこちらのほうが実用的かもしれない。
この設計は、Pine が useful signals without surveillance を強調する理由にもつながる。Agent status notification は、すぐに過剰な monitoring になりうる。すべての terminal output を読み、process を推測し、local workflow を server に送る方向だ。Pine の README では notification を verified events や detected process exits のような境界に寄せている。少なくとも位置づけとしては、local で説明可能で、privacy boundary が見えやすい signal を目指している。
Editor としての基本機能も省いていない
Terminal wrapper だけだと、すぐ半端な tool になる。Pine のもう一つの価値は、traditional editor capability もそれなりに揃えていることだ。LSP code intelligence は diagnostics、completion、hover、go-to-definition、code actions、rename、Problems panel を扱う。Syntax highlighting は Swift、TypeScript、Python、Go、Rust、Java、Kotlin、Ruby、C/C++ などの grammar を bundle している。Symbol navigation、code folding、minimap、find and replace、project-wide search、Quick Open、Markdown preview、status bar、bracket matching、large-file handling もある。
Git integration も普段の開発に近い。Sidebar の file status、gutter の diff markers、blame view、title bar や Git menu からの branch switching。Agent workflow では Git は飾りではない。Agent が file を変えたあと、人間が見たいのは、どの file が変わったのか、変更は function boundary に収まっているのか、module をまたいだのか、diagnostics は消えたのか、どの branch や worktree に戻るべきかだ。
Architecture の説明も比較的具体的だ。MVVM、SwiftUI views を AppKit の NSViewRepresentable で支える構成。Editor core は native NSTextStorage / NSLayoutManager / NSTextContainer stack。Syntax highlighting は background queue で asynchronous に走り、Git operations は GCD で parallel、project-wide search は Swift concurrency と sliding-window parallelism を使う。Web editor を desktop shell に入れたものではなく、macOS native stack にかなり寄せている。
Install は簡単だが platform は狭い
Pine の install path は Homebrew Cask が主になる。
brew install --cask batonogov/tap/pine-editorGitHub Releases から最新 .dmg を直接 download することもできる。Source build には macOS 26+ と Xcode 26+ が必要で、dependencies は Swift Package Manager で解決される。README には Sparkle auto-updates、さらに English、German、Spanish、French、Japanese、Korean、Portuguese (BR)、Russian、Simplified Chinese の localization も書かれている。
一番明確な caveat はここだ。Pine は macOS user 向けで、しかも新しい system と Xcode を要求する。Team が Windows、Linux、remote container、browser development environment にまたがっているなら、Pine を共通入口にするのは難しい。これは大規模な Electron IDE を置き換える universal tool というより、Mac を主力にし、CLI agent を日常的に使う個人 developer の local workspace に近い。
もう一つの caveat は project size だ。20 stars、0 forks、公開 issues は 11。Community validation はまだ早い段階にある。Latest release と commits が活発なのは良いが、main editor として使うなら、まず critical ではない project で試し、crash recovery、terminal session restore、LSP behavior、large-file handling、Git operations が自分の使い方に合うかを見たほうがいい。
誰が試すとよさそうか
Pine が合う user は三つある。
第一に、Claude Code、Codex、Gemini CLI、OpenCode を日常的に使っている macOS developer。Agent を terminal から出したくはないが、code、terminal、Git、diagnostics、agent status を同じ native window で見たい人だ。
第二に、複数の小さな project を同時に見ている人。Agent session が散ると、Cross-project Agent Inbox と exact live session routing の価値は単一 project より分かりやすい。「どの session に戻るべきか」という低レベルの摩擦を減らす。
第三に、local tool と native performance を好む人。Pine は Electron runtime を持たず、SwiftUI / AppKit と system text components に寄せている。それだけですべての体験が良くなるわけではないが、少なくとも browser app の再包装ではなく、macOS desktop capability に賭けている。
向かない場面もはっきりしている。Team が VS Code extension ecosystem に強く依存している場合、または作業の中心が remote Linux desktop、browser IDE、container workspace にある場合、Pine の macOS-native advantage は migration cost を上回らないかもしれない。Agent をたまにしか使わないなら、既存 editor と terminal split で十分なことも多い。
まとめ
batonogov/pine の価値は、「また別の AI editor」ではない。CLI agent がすでに現実の workflow に入っていることを前提に、editor をその事実の周りへ整理している点だ。Agent は terminal で動き続ける。Code は editor で見続ける。LSP、Git、terminal、notifications、cross-project task state が、その二つをつなぐ。
Project はまだ若く、platform boundary も狭い。それでも Gumi で記録する価値はある。小さく、具体的で、最近活発に更新されていて、developer がすでに感じている workflow friction を扱っている。Mac で CLI agent を重く使っている人なら、Pine は試用 list に入れてよい tool だと思う。