認証情報が消えていたのに、フラグのせいだと誤診した

何が起きたか

自作の業務システムには、claude CLIを呼び出して動く秘書役のエージェントが 組み込まれている。ある日、それが claude-cli exited with code 1 で失敗した。 手で叩くと、出てくる文言は Not logged in · Please run /login。

この文言には見覚えがあった。以前、CLIのあるバージョンで claude -p --bare が 認証ストアを読まずに同じ文言で失敗する、という挙動に当たっていた。そのときは --setting-sources "" を代わりに使えば認証が通ることを実機で確かめ、 回避策として記録していた。

現場の混乱

AIコーディングエージェントは、その記憶に引っ張られた。まずフラグを疑い、 書き方を変えて順に試した。--bare 付き、--setting-sources "" 付き、 何も付けない素の claude -p。

結果は全部同じだった。どれも Not logged in · Please run /login で落ちる。

ここでエージェントが出した結論は「回避策が効かなくなった」だった。以前は --setting-sources "" で通っていたのに、今は通らない。だから回避策が壊れた。 筋は通って見えるが、比較の前提が崩れていた。全部が同じ結果になるのは、 フラグの差が消えたからではなく、差を生む土台が無かったからだ。

原因

ログインの資格情報ファイル（~/.claude/.credentials.json）も、キーチェーンの エントリも、どちらも存在しなかった。ログインが丸ごと消えていた。残高の問題 でもフラグの問題でもない。

認証情報がそもそも無ければ、どのフラグで呼んでも同じ文言で失敗する。 その状態でフラグ同士を比べても、差が見えないのは当たり前だ。エラー文言が 過去の既知の問題と一致したことで、診断が「前と同じ原因」の側から始まり、 いちばん手前の確認が飛ばされた。

対策

• ターミナルで claude を起動して /login を実行し、サブスクリプション側の アカウントを選んでブラウザで認可した。これで復旧した。
• 「Not logged in」が出たら、まずフラグを疑わない。資格情報ファイルと キーチェーンを見て、認証情報がそもそも在るかを先に確かめる。
• 全ての書き方が同じ結果になったときは、「全部壊れた」ではなく「共通の 前提が無い」を疑う。比較が意味を持つのは、土台が揃っているときだけだ。

この診断順序は、以前の回避策のメモの冒頭に書き足した。次に同じ文言を見た エージェントが、同じ近道を取らないように。