設定ファイルをいじったのに反映されてないっぽい時、いま動いてるClaudeが何を読んでるか確認したい人向け
設定ファイル（settings.json）を書き換えたのに動作が変わらない時、いま動いてるモデルが何か分からなくなった時、応答が遅い・ログインが切れた気がするなど環境側のトラブルを切り分けたい時に叩く。Claudeが応答を返している最中でも開けるので、止めずに環境確認できる
/status は、いま動いてるClaude Codeが「どのバージョンで」「どのモデルで」「どのアカウントで」「どの設定ファイルを読んで」動いているかを一画面で見せてくれるスラッシュコマンドです。設定をいじったのに動作が変わらない時、このコマンドで「自分が編集した設定ファイル、そもそも読まれてる？」を真っ先に確認できます。
これ意外と知られてない。設定が効かないと「書き方が間違ってるのかな」とコードを書き直してしまいがちですが、実は別の場所の設定に上書きされてるだけ、というケースが多い。/status はその切り分けの最初の1手です。
噛み砕くと
新しい職場の初日、自分のパソコンに渡された設定が「会社全体のルール」「部署のルール」「自分用のルール」の3層に分かれてて、しかも上の層が下の層を上書きするとします。「自分のメモ帳に書いたルールが効いてない」と思ったら、まず会社全体のルールが上書きしていないかを確認しますよね。
/status はその確認画面です。Claude Codeも設定ファイルが何層にも重なって動いていて、上の層が下を上書きするので、「いまどの層が効いているか」を見ないと原因が特定できません。
大事な前提：このコマンドは「設定の中身」までは見せない
/status が見せてくれるのは、いま効いている設定ファイルの「一覧」と、Claude Code自体の状態（バージョン・モデル・アカウント・接続）です。「settings.json の中で具体的にどのキーが効いているか」までは出しません。
キーごとの妥当性を見たいなら別コマンドの /doctor、いま読み込まれてるCLAUDE.md の中身を見たいなら /memory、コンテキストウィンドウの埋まり具合を見たいなら /context と、用途で分かれています。/status は「どの設定ファイルが効いているか」を確認する入口、と覚えるのが一番近い。
「副業の料理ブログ」を例に、実際の手順を見る
料理ブログの下書きをClaude Codeに手伝ってもらってる最中、Pythonで画像のリサイズを自動化したくなったとします。.claude/settings.json に "Bash(python3:*)" を許可リストに足したのに、走らせるたびに「python3 を実行していいか」と毎回確認が走って止まる。設定が効いてない。
ステップ1: そのまま画面で /status を打つ
料理ブログの作業中だろうと、レスポンスが返ってきている最中だろうと、チャット欄で /status を打って Enter で開けます。Claudeの返答を待つ必要はありません（/status はレスポンス中でも動く数少ないコマンドの1つ）。
> /statusステップ2: Settings画面のStatusタブが開く
すると Settings interface（設定画面、複数タブのGUI）が開いて、Statusタブが選ばれた状態で表示されます。ここに version / model / account / connectivity / active settings sources が並びます。
ステップ3: active settings sources の欄を見る
料理ブログの例だと、ここに以下のような感じで複数の settings.json が並びます。
Active settings sources:
- managed settings (in effect)
- user settings (~/.claude/settings.json)
- project settings (.claude/settings.json)
- local settings (.claude/settings.local.json)注目するのは「managed settings」の行に (in effect) が付いているかどうか。これが付いていたら、組織管理者が配信した設定が一番上で動いていて、自分が .claude/settings.json に何を足しても、許可リストや禁止リストはそっちが優先されている可能性があります。
ステップ4: モデル欄も合わせて見る
「いま自分のモデル何だっけ」も同じ画面で確認できます。Statusタブの上のほうに model: claude-opus-4-7 のような形で出ます。/statusline で画面下のステータスバーを設定してれば常時見えますが、設定してない人はここが現モデル確認の場所です。
ステップ5: connectivity と account も一目で確認
同じ画面でログインしてるアカウント（Pro / Max / Team / Enterprise / API のどれか）と、Anthropic APIに繋がっているかどうかの接続状態も出ます。「急に応答が遅い」「ログインが切れた気がする」という時、まずここで切り分けます。
ステップ6: 原因が managed settings だった場合の動き方
managed settings に (in effect) が付いていた場合、自分のプロジェクトの .claude/settings.json に何を書き足しても、組織管理者の設定が上書きするので、自分側で解決できません。組織管理者（情シス担当）に「python3 実行を許可してほしい」と相談する、または個人アカウントに切り替える、のどちらかです。
ここで初心者がやりがちな勘違いがある。「managed settings が効いてる = エラー」ではありません。組織アカウントなら正常な状態。ただ自分が手元で書き換えてもムダ、というだけです。
つまり /status は何をしてくれるのか
- やってくれる: いま動いてるClaude Codeのバージョン・モデル・アカウント・接続状態・効いている設定ファイル一覧を一画面で見せる。レスポンス中でも開ける
- やってくれない: 設定ファイルの「中身」までは見せない（どのキーがどう効いてるかは
/doctor側）。コンテキストの埋まり具合も見せない（こっちは/context）。トークン消費・料金も見せない（/usageまたは/cost） - 意味が薄い場面: 設定をいじってない、モデルもいじってない、トラブルもない、という普段の作業中は開く必要なし。困った時だけ叩くコマンド
使いどころ3シナリオ
シナリオ1: 設定を書き換えたのに動作が変わらない時
料理ブログのプロジェクトで .claude/settings.json に Python 関連の許可ルールを足したのに、毎回 python3 実行確認で止まる。/status で active settings sources を見て、想定外の層（managed settings や別のプロジェクト設定）が効いていないかを最初に切り分けます。設定の優先順位は managed → user → project → local の順で上書きされるので、自分が編集したファイルより上の層が同じキーを持っていれば、当然下の層は無視されます。これに気付かずコードを書き直して何時間もムダにする、が一番もったいないパターン。
シナリオ2: 「いま自分のモデル何だっけ」になった時
家計簿アプリを作る作業を再開した時、前回 /model sonnet で切り替えたのか opus のままなのか分からなくなる、という場面。/status を打てば一発で model: claude-opus-4-7 みたいに出ます。/statusline で画面下にモデル名を常時表示する設定をしてれば不要ですが、その設定をしてないなら /status が現モデル確認の正規ルートです。/model をそのまま（後ろに何も書かずに）叩いてモデル選択画面（ピッカー）を開いてもいいですが、その画面は「次に切り替えるモデルを選ぶ画面」なので、現状確認だけしたい時は /status のほうが速い。
シナリオ3: 急に応答がおかしい・ログインが怪しい時
OSSをcloneして触り始めた直後、Claudeの返事が異常に遅かったり、エラーで返ってきたりする。「自分の書き方が悪いのか」「APIが落ちてるのか」「ログインが切れたのか」を切り分けたい時、/status で connectivity と account を確認します。connectivity が異常なら Anthropic 側のステータスページを見に行く、account 表示が想定と違うなら claude logout & claude login でログインし直す、と次の一手が決まります。原因切り分けの起点として置いておくコマンドです。
初心者が踏みやすい落とし穴
/statusと/statuslineを混同する。名前が似てるが完全に別物。/statuslineは画面下のステータスバー（モデル名・ディレクトリ名などを常時表示する帯）をカスタマイズするコマンド。/statusは環境情報の確認画面を開くコマンド。typo すると違うことが起きるので注意/statusと/usage（/cost）を混同する。/usageは今月のトークン消費量・料金・使用回数の確認。/statusは環境情報。「自分の使用状況」という言葉でひとくくりにすると混乱するので、/status= 環境、/usage= 消費量、と分けて覚える/statusと/contextを混同する。/contextはコンテキストウィンドウ（いま会話で覚えていられる文章量）の埋まり具合を可視化するコマンド。/statusはそれを見せない。「会話が長くなって動作が重い」と感じた時は/context、「設定が反映されてない」時は/status/statusだけで設定の中身まで見ようとする。これは見えません。/statusは「どの settings.json が active か」までで、その中のキー値・妥当性は/doctorでチェックする、と役割分担している- 「managed settings (in effect)」を見て焦る。組織アカウントで使ってるなら、これが出ているのが正常状態。エラー表示ではない。「自分が書き換えても上書きされる層が動いてる」というだけの事実情報
- レスポンス中に開けないと思い込む。
/statusは公式ドキュメントで「Works while Claude is responding」と明記されている数少ないコマンドの1つ。Claudeが長文を返してる最中でも開ける /statusを叩いただけで設定が直ると思う。これは確認専用のコマンドなので、何も書き換えません。原因が分かったあと、.claude/settings.jsonを直接編集するか、組織管理者に連絡するかの「次の一手」は自分でやる必要がある
書き方
/statusやってみるとこうなる
入力
> /status出力例
Settings画面のStatusタブが開いて、以下のような情報が並ぶ：
Version: 2.1.117
Model: claude-opus-4-7
Account: user@example.com (Max plan)
Connectivity: Connected to api.anthropic.com
Active settings sources:
- managed settings (in effect)
- user settings (~/.claude/settings.json)
- project settings (.claude/settings.json)
- local settings (.claude/settings.local.json)
※「managed settings (in effect)」が出ていたら、組織管理者が配信した設定が一番上で効いていて、自分側で何を書き換えても上書きされる状態このページに出てきた言葉
- Settings interface
- Claude Codeの設定画面。複数のタブに分かれていて、<code>/status</code>はその中のStatusタブを直接開く
- active settings sources
- いま効いている設定ファイル（<code>settings.json</code>）の一覧。Claude Codeは複数の設定ファイルを重ねて動かしていて、どれが今アクティブかを表す
- managed settings
- 組織管理者（会社の情シス担当など）が配信する優先度最高の設定。これが効いていると、自分でどう書き換えても上書きされる
- connectivity
- 接続状態。Anthropic APIにちゃんと繋がっているかどうか
- /statusline
- 画面下のステータスバーをカスタマイズする別コマンド。名前が似ているが <code>/status</code> とは別物
- /doctor
- 設定ファイルの中のキーが正しい書き方かを検証する別コマンド。<code>/status</code>が「どの設定ファイルが効いてるか」までなら、<code>/doctor</code>は「中身が正しいか」
- /context
- コンテキストウィンドウ（Claudeがいま覚えていられる文章量）の埋まり具合を可視化する別コマンド
- /usage
- 今月のトークン消費量・料金・使用回数を表示する別コマンド。<code>/cost</code>と<code>/stats</code>はこのエイリアス