Claude Code を日々どう使っているか: tmux、パーミッションモード、そしてスマホ

Claude Code は Anthropic のコーディングエージェントです。Claude アプリと同じ Claude のモデルで動きますが、動く場所は自分のマシンの上で、そこでファイルを読み、シェルのコマンドを実行し、コードを書き換えることができます。Claude の有料プランに含まれています。私は VS Code 拡張やデスクトップアプリではなくターミナルで使っています。ラップトップのひとつの tmux セッションの中に五つのセッションがあり、ほぼすべてがパーミッションの確認をオフにして起動したもので、スマホからは Claude アプリの Remote Control、SSH、あるいはチャットボット経由で届きます。

以下では、その環境を詳しく書きます。数字は記憶ではなく、自分のマシンから取ったものです。設定ファイル、Claude Code が ~/.claude/projects に残すセッションのトランスクリプト(私の場合は8月28日までさかのぼれます)、そしてプロンプトの履歴です。履歴は2月から始まっていて、7,323 件のプロンプトが入っています。

Claude と Claude Code は別物

#

Claude はモデルのファミリーのことであり、claude.ai やデスクトップ、スマホでそのモデルと話すチャットアプリのことでもあります。Claude Code は、そのモデルの上に作られたエージェントです。プロジェクトのフォルダで起動すると、そこでループしながら働きます。ファイルを読み、コマンドを実行し、コードを編集し、テストを走らせ、仕事が終わるか、こちらの判断が必要になるまで続けます。Claude に何かの直し方を聞けば、答えが返ってきます。Claude Code に聞けば、修正そのものと、読むべき diff が返ってきます。

私は両方使っています。10月18日から、私が作っているマーケットプレイス兼コミュニティアプリは Django のバックエンドから Claude API に直接翻訳を送っていて、その切り替えの変更は Claude Code のセッションで行いました。トランスクリプトを見ると、返答の 94% は Opus 5.5 からのもので、設定の effort レベルは high にしてあります。

ネイティブインストーラーは一行で、あとは自分で最新に保ってくれます。

curl -fsSL https://claude.ai/install.sh | bash

~/.local/bin に、~/.local/share/claude/versions/ の中を指す claude のシンボリックリンクが置かれます。私のものは10月21日に、勝手に 2.1.305 から 2.1.306 に上がっていました。Claude Code を使うには、Claude の有料プラン(Pro、Max、Team、Enterprise)か API アカウントが必要です。料金はしょっちゅう変わるので、Anthropic の料金ページに任せます。

ひとつの tmux セッションに七つのウィンドウ

#

これを書いている今、tmux list-panes -a を実行すると、ラップトップには main というセッションがひとつあり、ウィンドウが七つあります。そのうち五つが Claude Code で、プロジェクトごとにひとつずつです。私が作っているマーケットプレイスアプリと見積もりアプリ(どちらも今の技術スタックで紹介しています)、このブログ、それに小さなものが二つ。ターミナルのプロファイルはどのウィンドウもログインシェルで開き、そのシェルが main にアタッチします。なので、ラップトップで新しいタブを開いても、スマホから SSH でログインしても、同じセッションにたどり着きます。

9月17日から10月8日までは別のマルチプレクサを試していましたが、tmux に戻りました。理由は実用的なものです。スマホの SSH アプリは tmux で多重化していて、ショートカットボタンが tmux の標準のキーを送ってくるのです。~/.tmux.conf のこういった行は、スマホのためにあります。

set -g prefix C-a                 # Ctrl-a prefix
set -g prefix2 C-b                # stock Ctrl-b too, for apps that send it

# Size each window to the client that used it last, not the smallest one,
# so a phone attached to the same session doesn't shrink it.
setw -g window-size latest

# Copy to the clipboard of whichever terminal is attached (OSC 52),
# so over SSH it lands on the phone's clipboard too.
set -g set-clipboard on

tmux の中では、二つのことが変わります。Claude Code は実行中のコマンドを Ctrl+B でバックグラウンドに回しますが、これは今では私の二つ目の tmux プレフィックスです。そこで ~/.claude/keybindings.json でこれをオフにして、代わりに Meta+B を使っています。

{
  "bindings": [
    { "context": "Global", "bindings": { "ctrl+b": null } },
    { "context": "Task", "bindings": { "ctrl+b": null, "meta+b": "task:background" } }
  ]
}

もうひとつは改行です。Enter はプロンプトを送信します。ドキュメントでは、どのターミナルでも動くものとして、\ のあとに Enter と、Ctrl+J の二つを挙げています。Option+Enter は、ターミナルが Option を Meta として送るように設定すれば動きます。Shift+Enter はそのままで動くターミナルもありますが、tmux は extended-keys をオンにしないとこれを通しません。私はオンにしていないので、私のセッションでは Shift+Enter を押すとプロンプトが送信されます。とはいえ、どれもめったに使いません。7,323 件のプロンプトのうち、自分で打った改行を含むのは 84 件だけで、貼り付けを含むものは 279 件あります。貼り付けたテキストは、Claude Code が [Pasted text #1 +34 lines] のようなプレースホルダーにたたんでくれて、中身は全部送られます。

ターミナル、VS Code 拡張、デスクトップアプリのどれにするか

#

同じエージェントがいくつかの包装で提供されていて、どれも同じ設定ファイルを読みます。Claude Code が各トランスクリプトに記録しているエントリーポイントで分けると、私のセッションはこうなります。

私の場合はターミナルで、愛着があるからではありません。スマホからアタッチする tmux にはターミナルが必要ですし、チャンネルもそうです。チャンネルは外部のイベントをセッションに流し込む仕組みで、ドキュメントでは CLI の機能として挙げられています。

Claude Code に git は必要か、ともよく聞かれます。CLI には要りません。私のホームディレクトリはリポジトリではありませんが、私のプロンプトのうち 208 件は、そこで起動したセッションに送ったものです。デスクトップアプリのドキュメントには、セッションごとに専用の worktree を持たせるセッションの分離に git が必要だと書かれていますし、クラウドのセッションをターミナルに引き込むには同じリポジトリのチェックアウトが要ります。私自身は「Git is required for local sessions」というメッセージを見たことがありません。最後にデスクトップアプリを使ったのは10月20日で、そのセッションはリポジトリでもなんでもないフォルダで動いていました。

パーミッションモードと、実際に使っているもの

#

パーミッションモードは、Claude Code がどれくらいの頻度で手を止めて確認してくるかを決めるもので、Shift+Tab でモードを順に切り替えられます。Manual(default)は、ファイルの編集、コマンドの実行、ネットワークへのアクセスを伴うほとんどの操作の前に確認します。acceptEdits は、ファイルの編集とよくあるファイルシステムのコマンドを通します。plan は読んで提案するだけで、編集はしません。auto では、二つ目のモデルである分類器が、こちらに聞く代わりに危険な操作をブロックします。bypassPermissions は、ほとんど何も聞いてきません。バージョン 2.1.283 からは、特に指定しなければ、ターミナルのセッションは auto モードで始まります。

なので「Claude Code に許可を求めさせずに動かすにはどうすればいいか」への私の正直な答えは、こう起動している、です。

claude --dangerously-skip-permissions

シェルの履歴にある 69 回の claude コマンドのうち 62 回にこのフラグが付いていて、今動いている五つのセッションもすべてそうです。8月28日から10月21日までに打った 1,266 件のプロンプトのうち、1,179 件は bypass モードのセッションに、82 件は auto モードに、5 件は Manual か accept-edits に送ったものでした。

ドキュメントははっきり書いていて、bypass モードは「インターネットにアクセスできないコンテナ、VM、dev コンテナのような、Claude Code がホストシステムを壊しようのない隔離された環境」向けだとしています。私のラップトップはそのどれでもなく、設定にはその警告をクリックで通過した記録が残っています("skipDangerousModePermissionPrompt": true)。同じことをするなら、bypass モードでは allow ルールが効かないことは知っておいてください。つまり私の普段のセッションでは、19 個の設定ファイルに散らばった 378 個の allow ルールは、何ひとつ仕事をしていません。deny と ask のルールは bypass モードでも効きますが、私はどちらも一つも書いていません。

例外は、ほかの人の言葉を読むセッションです。そのランチャーはこのフラグを渡さないので、auto モードで始まります。10月12日から20日までにセッションに届いた本番イベント 27 件はすべて、チャットのメッセージは 43 件のうち 42 件が auto モードで受け取ったもので、bypass で受け取ったものはひとつもありません。

bypass モードで実際に痛い目を見ずに済んでいるのは、いくつかの習慣のおかげです。どれも、一度失敗したあとで Claude のメモリに書き込んだものです。9月10日、いくつものセッションがマーケットプレイスアプリの同じチェックアウトで作業していたとき、一行の修正が四回のビルド失敗を生き延びたあと、コミットされる前に消えてしまいました。別のセッションがそのファイルを上書きしていて、git には何の記録も残っていませんでした。同じ日、あるセッションのコミットしていない作業が、デプロイで危うく出荷されかけました。デプロイスクリプトが HEAD ではなく作業ツリーをビルドするからです。それ以来のルールはこうです。小さな修正は動いた瞬間にコミットする。ファイルは名前を指定してステージし、git add -A は決して使わない。git status を見て、自分が入れていない変更がないか確かめる。そして main にほかのセッションのまだデプロイしていない作業が載っているときは、本番に出ているコミットの worktree からデプロイする。

スマホから届く

#

入り口は三つあって、それぞれ届く先が違います。

Remote Control は、スマホの Claude アプリやブラウザの claude.ai/code を、ラップトップで動き続けているセッションにつなぎます。ファイルもツールも MCP サーバーもそのまま使えます。9月13日から10月20日までに /rc を 26 回打ちました。今は remoteControlAtStartup をオンにしていて、新しいセッションは勝手につながります。10月に入ってから起動した 77 のセッションのうち 67 に Remote Control のリンクがあり、9月後半は 52 のうち 3 でした。agentPushNotifEnabled をオンにしておくと、Claude は必要だと判断したときにプッシュ通知を送ってきます。ドキュメントによれば、たいていは長いタスクが終わったときか、判断が必要になったときです。API キーではなく claude.ai のサブスクリプションが必要で、セッションはラップトップで動いているので、ラップトップは起きていなければなりません。10月15日から、私のラップトップは蓋を閉じてもスリープしません(sudo pmset -a disablesleep 1)。

逆向きもできます。/teleport か claude --teleport を使うと、Web やアプリで始めたクラウドのセッションを、ブランチと会話ごとターミナルに引き下ろせます。私がやったのは二回で、どちらも7月です。

SSH は、ターミナルそのものが欲しいときに使います。スマホはプライベートネットワークの記事で書いたプライベートネットワーク越しにラップトップに届き、エイリアスひとつで main にアタッチするので、ラップトップに置いてきたウィンドウをスワイプで行き来できます。Mac がスマホのアプリにちゃんと応答するようになるまでには四つの別々の修正が必要でしたが、Claude Code に関係があるのは、tmux を決して勝手に起動させないことです。docker ps を実行しようとセッションを開いたアプリが、結果の代わりに 72 KB 分の画面の再描画を受け取っていたのです。

チャットボットは、座って見張っていたくないセッションのためのものです。10月12日から、あるセッションを、自分で書いた小さなチャンネルと一緒に動かしています。このチャンネルはアプリのサーバーを一分ごとに確認し、新しい本番エラーやプロジェクトボードの動きがあればセッションに渡します。そこに公式のチャットプラグインのひとつも組み合わせているので、許可リストに載っている私たち二人がメッセージを送れます。起動の行は、名前を一般的なものにするとこんな形です。

exec claude \
  --channels plugin:<chat-plugin>@claude-plugins-official \
  --dangerously-load-development-channels server:my-events "$@"

スーパーバイザーのスクリプトが、tmux の中でこれを動かし続けています。再起動したあとは同じ会話を再開するので、セッションはまっさらな状態で目覚めるのではなく、続きから作業します。再起動のたびにチャットで知らせもします。セッションは作業ツリーで修正をして、そこで止まります。例外がひとつあって、10月13日に足しました。本番で実際にユーザーを困らせているバグなら、修正し、テストし、コミットし、デプロイまでしてから、何をしたかを私たちに伝えてよいことにしています。

スキル、メモリ、/goal

#

私の設定ファイルには、どれにも hooks キーがありません。いちばん近いのは /goal で、7月11日から 279 回使っています。条件を受け取って、そのセッションに Stop フックを設定するもので、Claude Code の言葉を借りれば「条件が満たされるまで停止をブロックする」ものです。私のゴールは、口に出して言うときのままの文面です。7月の実例をひとつ挙げると、タイプミスもそのままに、ビルドが “still broken, try a deeper fix and dont stop until”(まだ壊れてる、もっと根っこから直して、止まらないで)、テスターの手に届くまで、と書いていました。長い実行を脱線させずに様子を見るには /btw があります。会話の本筋には残らない、横からの質問です。私のはたいてい “hows it going?"(調子どう?)のバリエーションです。

スキルには、そうでなければ毎回説明することになるものを入れています。あるユーザーレベルのスキルは、このブログを含め私が面倒を見ているサイトの週次キーワードレポートを読み、タイトル、description、タグに反映します。この記事が答えている質問は、10月18日付のこのブログ向けのレポートから来たもので、スキルのファイルはリポジトリで、コードと一緒にバージョン管理しています。マーケットプレイスアプリのリポジトリには専用のスキルがあります。ひとつは Docker で API を起動してスモークテストを走らせるもの、ひとつはプロジェクトボードを扱うもの、もうひとつは会社の経費を申請するものです。インストールしているプラグインは、Swift の言語サーバーのプラグインとチャットのプラグインの二つです。

メモリは教訓の置き場所です。17 のプロジェクトにまたがって 160 個のメモリファイルがあり、そのうち 83 個がマーケットプレイスアプリのもので、多くは何かが壊れたときの話です。アプリの CLAUDE.md は、6月の約六倍の長さにまで育ちました。このブログの CLAUDE.md は空のファイルで、記事をどんな声で書くかは、代わりにメモリファイルに入っています。

大きな仕事では、Claude はサブエージェントを起動します。メインのセッションで 120 回、そのうち 40 回は会話のフォークです。このブログの日本語、韓国語、中国語、ベトナム語版も、そうやって作っています。10月19日と20日には、アプリのコミュニティ機能のリデザインが Workflow ツールを四回通りました。まず、七つの観点と一人の批評役による監査で、約 58 件の指摘が確認されました。次に、それぞれ自分のファイルを受け持ち、それぞれレビューを受けた五つのグループによる修正。それから積み残しを片付けるパス。最後に、すべての指摘が直ったかどうかの独立した確認です。リリースは20日でした。

devbox の出番

#

プライベートネットワークの記事は、重い仕事をオフィスの GPU 付きワークステーション devbox に置いて、どこからでもそこに届くようにする話でした。その「届く」の大半をやっているのは Claude Code です。9月24日から10月19日までに、ラップトップの 21 のセッションが、素の ssh で devbox 上のコマンドを 1,470 回実行しました。そこで動いているクラスタへの kubectl、データベースの Pod の中での psql、長いジョブの進み具合を見るための tmux capture-pane。オフィスのネットワークの外では ssh devbox がトンネルにフォールバックするので、同じセッションがオフィスでも自宅でもカフェでも動きます。それにラップトップはもうスリープしないので、私がスマホから様子を覗いているあいだも、セッションは devbox を操作し続けられます。

Claude Code か Codex か

#

Claude Code が Codex より優れているかどうかは、自分の使用経験からは言えません。理由は表を見れば分かります。

一週間で四スレッド、それも画像についての質問、Web サイトへの二つの変更、3D シーンというのは試用であって、比較ではありません。ただ、そこで出てきたひとつのことは、どのエージェントからどのエージェントへ乗り換えるときにも当てはまります。3D のプロジェクトはルールを claude.md に置いていて、私がそこで Codex に最初にした質問は、会話の前に Claude のファイルを読むかどうかでした。答えは読まない、で、プロジェクトのルールを拾ったのは、私がそのファイルを読むように頼んでからでした。どのエージェントに移るにしても、指示のファイルは自分で持っていかない限り置き去りになります。それ以来、Codex のスレッドは開いていません。9月24日から10月4日までのあいだの数日、私が何も始めていないのに拡張が VS Code に読み込まれていましたが、今はアンインストールしてあります。

というわけで、自信を持って言える結論は狭いものです。私の環境は Claude Code を中心に組んであり、Codex が今同じことをどう扱うのかは、戻って確かめていません。

最後に、ここまでのどれよりも私の使い方をよく表している数字をひとつ。8月下旬以降、ラップトップのメインのセッションで、Claude Code は 18,311 回シェルコマンドを実行し、ファイルの読み込み・書き込み・編集を 2,331 回行いました。回数で見れば、仕事の大半は、そうでなければ私が打っていたはずのコマンドを、ラップトップでも SSH 越しでも、私がたまたまいる場所から実行することです。実際にコードを書くとなると、そのコードはどこでも歓迎されるわけではなく、それはそれで別の話として pyhtml2text の記事に書きました。