Claude Code での作業をしていて、個人的に重宝している設定やコマンドを7つ厳選して紹介します。
どれも導入が簡単で「入れる前後で作業の快適度が地味に変わったな」と感じたものだけを選びました。
ひとつずつ何が嬉しいかを書いていきます。
動作確認: Claude Code v2.1.126 / macOS Sequoia
設定キーや slash command は版差があるので、再現できないときは公式ドキュメントの最新版で挙動を確認してください。
最終的な設定内容
最終的な ~/.claude/settings.json はこんな感じです。
{
"env": {
"CLAUDE_CODE_NO_FLICKER": "1"
},
"cleanupPeriodDays": 999,
"statusLine": {
"type": "command",
"command": "npx -y ccstatusline@latest",
"padding": 0,
"refreshInterval": 10
},
"permissions": {
"allow": ["Bash(rg:*)", "Bash(jq:*)", "Bash(gh pr view:*)", "..."],
"deny": ["Bash(rm -rf:*)", "Bash(sudo:*)", "Read(./.env)", "..."]
},
"hooks": {
"Stop": [
{
"matcher": "",
"hooks": [{ "type": "command", "command": "bash ~/.claude/hooks/notify-stop.sh" }]
}
]
}
}
① CLAUDE_CODE_NO_FLICKER=1
permission prompt が出るたびに画面がチカっと再描画されたり、スピナーがブレたりするのが微妙に気になっていました。
CLAUDE_CODE_NO_FLICKER=1 を入れるとこれが収まります。中身は fullscreen alt-screen renderer の有効化で、/tui fullscreen を打つのと同じ動作（公式ドキュメント）です。
長時間セッションでメモリが膨らみにくくなる副作用もあります。
{
"env": {
"CLAUDE_CODE_NO_FLICKER": "1"
}
}
環境変数なので反映は次回起動から。まだ research preview 扱いですが、今まで使ってみて特に困ったことは起きていません。
~/.zshrc で export でも良いのですが、設定を1ファイルに集約したいので JSON で管理しています。
② statusLine で使用量やリミットを常時表示
Claude Pro / Max を使っていると、5時間ブロックと週次の使用量が気になります。これをステータスラインに常時出しておくと、Claude Codeの使用残量を加味してその日の作業の計画がしやすくなりました。
完成形:
Model: Opus 4.7 | Context: [▓▓░░░░░░░░] 119k/1000k (12%) | cwd: ~/workspace | Thinking: xhigh
Session: 7.0% | Reset: 4hr 22m
Weekly: 18.0% | Weekly Reset: 3d 22hr 12m
⌘main | ?
「あと 4 時間で 5h ブロックがリセットされる」みたいな時間感覚が視野の隅に置けます。
なぜ作れるのか
公式が statusLine の stdin に渡す JSON に rate_limits.five_hour.* / rate_limits.seven_day.* を含めてくれているからです。あとは widget 側がそれを読むだけ。
おすすめ: ccstatusline
ccstatusline という OSS を使うと、TUI で対話的にレイアウトを組めます。
npx -y ccstatusline@latest
Edit Lines から widget を並べていく感じ。僕は今こんな構成にしています。
- Line 1:
Model→Context Bar→cwd→Thinking Effort - Line 2:
Session Usage→Block Reset Timer - Line 3:
Weekly Usage→Weekly Reset Timer - Line 4:
Git Branch→Git Status
最後に Install to Claude Code を選ぶと、~/.claude/settings.json に下記が書き込まれます。
{
"statusLine": {
"type": "command",
"command": "npx -y ccstatusline@latest",
"padding": 0,
"refreshInterval": 10
}
}
ccstatuslineを使えば、簡単にどんな要素を表示できるか確認したり検証できるので、定期的にstatusLineの内容もアップデートしたいと思っています。
③ cleanupPeriodDays: 999 でセッションを実質永続化
しばらく気づいていなかったんですが、Claude Code はデフォルトで 30 日経つと過去のセッション履歴（~/.claude/projects/<hash>/*.jsonl）が消えます。
延長しておきたい理由は3つくらいあって、
-
Esc連打の巻き戻しが古いセッションでも効く -
claude -c/claude --resumeで過去セッションを蘇らせられる - 後から
/insightsで振り返れる、ccusage でコスト集計できる、claude-code-log で HTML 化できる、など分析ツールに渡せる
設定は ~/.claude/settings.json に1行。
{
"cleanupPeriodDays": 999
}
0 は使えないので注意
cleanupPeriodDays は最小値が1です。0 は validation error で弾かれます（公式ドキュメント）。
セッション履歴を丸ごと書かせたくない場合は別ルートで、
-
CLAUDE_CODE_SKIP_PROMPT_HISTORY=1で書き込みごと止める - 一時的なら
claude -p --no-session-persistenceで-pセッションだけ無効化 - SDK 経由なら
persistSession: false
長期保存したいだけなら 999（約2.7年）や 99999（実質無限大）でOKです。
一応のリスク
JSONL はプレーンテキスト保存なので、プロンプト全文・コマンド実行結果・たまに API キーまで残ります。個人マシン1人運用なら気にしなくていいですが、共有マシンや業務マシンでは気をつけてください。
容量は月 0.5〜1.5GB くらい（手元の感覚値）。3 年で 15〜50GB くらいの計算になります。
④ /insights で自分の使い方を振り返る
/insights は Claude Code に内蔵されている振り返りコマンドで、過去のセッション群を解析した HTML レポートが ~/.claude/usage-data/report.html に出力されます。
/insights
実行すると、ブラウザで開けます。
試しに直近1ヶ月分を解析した結果、「Claude が config キーを推測で答えて間違える」「16GB Mac なのに 19GB のローカル LLM を勧めてくる」のような、過去にClaudeが失敗した内容が整理されて返ってきました。今後同じミスをさせないために CLAUDE.md にどう書き加えるかやメモリに残すのかなどを考えるきっかけになるなと思いました。
レポートには Friction analysis 以外にも、うまく回っている使い方、CLAUDE.md への追記提案、まだ使っていない Skills / MCP の提案、なども入っていました。
ローカル処理オンリーで外部送信なしです。
⑤ claude -c で前回セッションを継続
claude -c（または --continue）で、直前のセッションをコンテキストごと継続できます。一度終了した後の作業再開が簡単にできます。ターミナルアプリが落ちてしまっても途中から再開できるので便利です。
claude -c # 直前のセッションを継続
claude --resume # セッション一覧が表示されるので復帰したいセッションを選択
cleanupPeriodDays: 999（③）と組み合わせると、3 年前のセッションでも claude --resume で蘇らせられます。
ひとつ注意点として、同じディレクトリで実行する必要があります（プロジェクト hash で紐付くため）。
⑥ /memory で読み込み中メモリを確認
セッション中に「今このプロジェクトで何が読み込まれてるんだっけ？」が知りたくなった時に使います。
/memory
実行すると、
- 読み込み中の
CLAUDE.md/CLAUDE.local.md/.claude/rules/**の一覧 - ファイルを選んで
$EDITORで開いて編集 - auto memory の ON/OFF トグル
- auto memory フォルダへのリンク
が出ます。$EDITOR を VSCode にしておくと選択即エディタで快適です。
export EDITOR='code -w'
個人的に特に便利だと感じたのは以下のシーンです。
-
.claude/rules/**をパスマッチで動的にロードしている時、ちゃんと読まれているかの確認 - auto memory が勝手に書いた内容を眺めて、要らないやつを消したい時
会話で「これ覚えておいて」と頼めば auto memory に記録されますし、明示的に書きたい時は /memory から開くのが現状は確実です。
⑦ permissions 3 階層 + hooks で自動化
permissions の 3 階層
毎回出る「このコマンド許可しますか？」を、意図ベースで設計します。
| 階層 | ファイル | 何を入れるか |
|---|---|---|
| user | ~/.claude/settings.json |
汎用 read-only（rg / jq / gh など）と deny |
| project | ~/<project>/.claude/settings.json |
プロジェクト固有 CLI（git 管理して共有） |
| local | ~/<project>/.claude/settings.local.json |
自分用の一時的な許可（.gitignore 対象） |
user level はこんな感じにしています。
{
"permissions": {
"allow": [
"Bash(rg:*)", "Bash(jq:*)",
"Bash(gh pr list:*)", "Bash(gh pr view:*)",
"Bash(gh issue list:*)", "Bash(gh issue view:*)"
],
"deny": [
"Bash(rm -rf:*)",
"Bash(sudo:*)",
"Read(./.env)", "Read(./.env.*)",
"Read(**/credentials*)", "Read(**/*secret*)",
"Read(~/.ssh/**)", "Read(~/.aws/**)"
]
}
}
ポリシーとしては、
- 書き込み・実行系は入れない（
git commit/git push/npm installは ask のままにしておく） - deny は事故防止の安全網として置く（普段は使わないけど暴走したとき用）
そして ls / cat / head / tail / grep / find / wc / diff / stat / du / cd と read-only な git コマンドは最初から auto-allow されています（公式ドキュメント）。なので Bash(git status:*) や Bash(find:*) を allow に書く必要はありません。
/fewer-permission-prompts スキル
過去のトランスクリプトをスキャンして、頻出する read-only コマンドを抽出してくれる公式スキルがあります。
/fewer-permission-prompts を起動すると、
-
~/.claude/projects/*/*.jsonlから Bash 呼び出しを集める - read-only に絞り込み（mutation 系・任意コード実行系を除外）
- 既に auto-allow されているコマンドを除外
- プロジェクトの
.claude/settings.jsonのpermissions.allowに追記
をやってくれます。僕の場合は ollama list / brew list のような定期的に使うが毎回許可を求められるコマンドが拾い出されました。
PostToolUse Hook で .py 編集後に ruff 実行
Claude が .py ファイルを編集した瞬間に、ruff で自動整形＋未使用 import 削除をかける hook です。
# ~/.claude/hooks/ruff-format.sh
#!/usr/bin/env bash
input=$(cat)
file=$(echo "$input" | jq -r '.tool_input.file_path // empty')
[ -z "$file" ] && exit 0
[[ "$file" != *.py ]] && exit 0
[ ! -f "$file" ] && exit 0
RUFF="$HOME/life/.venv/bin/ruff"
[ ! -x "$RUFF" ] && exit 0
"$RUFF" format "$file" >/dev/null 2>&1
"$RUFF" check --fix --quiet "$file" 2>&1 || true
exit 0
settings.json 側は Edit|Write ツールに対して上のスクリプトを呼ぶ設定。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{ "type": "command", "command": "bash ~/.claude/hooks/ruff-format.sh" }
]
}
]
}
}
動作確認をしたところ、ちゃんと整形されました。
# わざと崩した .py を作って hook に流す
cat > /tmp/test_ruff.py <<'EOF'
import os,sys
def foo( x,y ):
z=x+y
return z
EOF
echo '{"tool_name":"Edit","tool_input":{"file_path":"/tmp/test_ruff.py"}}' \
| bash ~/.claude/hooks/ruff-format.sh
cat /tmp/test_ruff.py
# →
# def foo(x, y):
# z = x + y
# return z
未使用の import os, sys まで削除されます。
Stop Hook で「応答完了通知」
Claude が応答を終えた瞬間に macOS の通知センターに飛ばす hook。長時間タスクの待ち時間に他のことをしていても気づけます。
# ~/.claude/hooks/notify-stop.sh
#!/usr/bin/env bash
osascript -e 'display notification "応答完了" with title "Claude Code" sound name "Glass"'
exit 0
{
"hooks": {
"Stop": [
{
"matcher": "",
"hooks": [
{ "type": "command", "command": "bash ~/.claude/hooks/notify-stop.sh" }
]
}
]
}
}
Hook を書く時に踏みやすいところ
-
PostToolUseのmatcherはツール名マッチで、Edit|Writeのように|で並べると exact-string-list として扱われます。^Notebookみたいに記号を入れると JS 正規表現として解釈される、という二段構え（公式ドキュメント） -
Stopにはmatcherがない。書いても silently に無視されるので、""で大丈夫 - スクリプトは stdin で JSON を受け取るので、
tool_input.file_pathあたりをjqで抜く - 基本は
exit 0を返す。ただStopでexit 2を返すと「応答完了させない」というブロック挙動になり、stderr が Claude に戻されて会話が継続します。意図せず使うと厄介なので注意。PostToolUseの方は非 0 でもログに残るだけで処理は流れます
最後に
今回紹介した７つのTipsをまとめます。
- ターミナルがちらつかない（①）
- サブスク残量が常時見える（②）
- 過去のセッションがいつでも蘇る（③）
- 自分の使い方を Claude に振り返ってもらえる（④）
- 切れても続きから再開できる（⑤）
- 何が読み込まれているかいつでも確認できる（⑥）
- 細かい permission 確認が減って、編集後の整形も勝手にかかる（⑦）
まずは導入が簡単で快適さ向上が即実感できる、ちらつき対策と statusLine から始めると良いと思います。