夜間の claude -p で MCP が「認証が必要」と出る朝に

朝、iMac の前に座って前夜の実行ログを開くと、MCP サーバーが一つも使われないまま、タスクが空振りで終わっていたことがあります。ログには「needs authentication」の一行。前の晩に認証は済ませてあるはずで、手元で claude を開けば同じサーバーが普通に繋がります。

最初のうち、私はこれを OAuth トークンの期限切れだと決めつけ、サーバーごとに再認証をやり直していました。結果は芳しくありませんでした。翌晩にまた同じ行が出るのです。原因は認証ではなく、夜のあいだに Mac がスリープしたこと、そしてログインキーチェーンがロックされていたことでした。

最初にお伝えしたいのは、無人の実行で MCP が落ちたら、サーバーや認証を触る前に、Mac の状態を疑うということです。この記事は、その順番を書き残したものです。

v2.1.307 で変わったこと

2026年10月21日に出た v2.1.307 のリリースノートに、この症状に直接かかわる修正が三つ入っています。

macOS でログインキーチェーンがロックされている間、claude -p の MCP サーバーが「needs authentication」と表示される問題。理由が表示されるようになり、アンロック後の次の実行では、再サインインなしで接続されるようになりました
MCP サーバーへ接続している最中に macOS か Linux がスリープすると、サーバーがタイムアウト扱いになり、ヘッドレス実行では失敗したまま残る問題の修正
接続が呼び出しの途中で閉じたとき、HTTP の MCP ツール呼び出しが二重に送られる問題。読み取り専用か冪等なツールだけが再試行されるようになりました

つまり、v2.1.306 以前では「認証が切れた」と「Mac が寝ていた」が同じ顔をして出ていた、ということになります。表示が変わっても、Mac の側の事情が消えるわけではありません。ここを切り分けておくと、次に同じ行を見たときに慌てずに済みます。

切り分けの順番

手順は短く、上から順に確認します。

1. 版を確かめる

claude --version
# 2.1.307 以上であれば、キーチェーンのロックは理由つきで表示される

2.1.306 以前なら、まず更新します。自動更新に任せている方は、claude update で手元の版が最新になっているかを一度見ておくと安心です。

2. その夜、Mac が寝ていなかったかを見る

# 前夜の電源まわりのイベントを、時刻つきで拾う
pmset -g log | grep -E "Sleep|Wake|DarkWake" | tail -n 20

実行の開始時刻と近い位置に Sleep があれば、接続中に寝た可能性が高いです。深夜の自動実行は、DarkWake（画面を点けない短い起床）で始まることがあります。その場合、接続の途中でまた眠ってしまう可能性があります。

3. ログインキーチェーンがロックされていなかったかを見る

# 設定（スリープ時にロックする設定か、ロックまでの秒数）を確認する
security show-keychain-info ~/Library/Keychains/login.keychain-db

この出力で分かるのは、lock-on-sleep が有効かどうかと、ロックまでのタイムアウトまでです。いま閉じているかどうかは、出力だけでは断定できません。それでも「スリープでロックされる設定か」は、夜間実行の前に知っておく価値があります。画面ロックやスリープを挟んでキーチェーンが閉じると、保存済みの認証情報を読めなくなります。無人の実行では、パスワードを入力する人がいません。

4. 版を上げても残る部分を知っておく

v2.1.307 の修正は、「理由を表示する」「アンロック後は再サインイン不要」というところまでです。夜のあいだキーチェーンが閉じていれば、その実行自体は MCP なしで進みます。表示が正直になっただけで、動かない夜がなくなったわけではありません。 ここは、自分の側で守る必要があります。

実行前に置いている確認スクリプト

私は夜間の claude -p を、次のようなラッパー経由で回しています。起きている Mac で、キーチェーンが開いていて、版が足りているときだけ走らせる、という線引きです。

#!/bin/bash
# nightly-claude.sh — 無人実行の前に Mac の状態を確かめる
set -u
 
MIN="2.1.307"
CUR="$(claude --version | awk '{print $1}')"
 
# 版が MIN 未満なら実行しない（sort -V で版番号を比較）
if [ "$(printf '%s\n%s\n' "$MIN" "$CUR" | sort -V | head -n 1)" != "$MIN" ]; then
  echo "SKIP: claude $CUR は $MIN 未満です" >&2
  exit 2
fi
 
# キーチェーンに触れなければ、理由をログに残して終了（目安であり、ロックの断定ではない）
if ! security show-keychain-info ~/Library/Keychains/login.keychain-db >/dev/null 2>&1; then
  echo "SKIP: ログインキーチェーンの確認に失敗しました" >&2
  exit 3
fi
 
# caffeinate -i で、このコマンドが走っているあいだはアイドルスリープを止める
caffeinate -i claude -p "$(cat "$1")" --permission-mode default

caffeinate -i が止めるのはアイドルスリープだけで、蓋を閉じたノート Mac のスリープまでは止められません。iMac で運用している私の場合はこれで足りていますが、ノート Mac の方は電源接続と蓋の開閉を別に確かめていただければと思います。

なぜ終了コードを分けているかというと、翌朝のログを見たときに「版の問題」「キーチェーンの問題」「それ以外」を、一行で見分けたいからです。認証をやり直す前に、この数字を見ます。

つまずいた点

一つ目は、security show-keychain-info をロックの有無の判定に使えると思い込んでいたことです。実際には設定値を返すコマンドで、いま閉じているかまでは教えてくれません。このラッパーでは「キーチェーンのファイルにアクセスできるか」の目安としてだけ使い、>/dev/null 2>&1 で受けて戻り値を見ています。確実に開けたいときは、security unlock-keychain を実行前に別途用意する必要があります。

二つ目は、HTTP の MCP ツールが「二重に送られる」問題です。v2.1.307 以降は、読み取り専用か冪等なツールだけが再試行されます。ということは、書き込みを伴うツールは、接続が途中で切れても再試行されないということです。夜間の実行では、書き込み系のツールの結果を、翌朝に自分の目で確かめる習慣が要ります。

版を上げたあとに、確かめておくこと

更新した直後は、無人の実行を一度、昼間に手動で回してみてください。MCP の接続状況は、実行の途中で claude mcp list を打てばわかります。つながっているサーバーの数が、手元で claude を開いたときと一致していれば、とりあえずは大丈夫です。

関連する症状は、別の記事にも書いています。MCP が突然動かなくなったときの全体の診断はこちらに、リモート MCP の OAuth トークンの寿命についてはこちらにまとめています。スリープとは別の理由で接続が60秒で切れる場合は、タイムアウト設定の記事も参考になるかもしれません。

認証を疑う前に、Mac が起きていたかを先に見ます。 この一手間だけは、疲れている朝でも守るようにしています。

次に同じ行を見つけたときは、まず pmset -g log の末尾 20 行を開いてみていただければ幸いです。私もそこから始めました。

夜間の claude -p で MCP が「認証が必要」と出る朝に、Mac のスリープとキーチェーンを疑う順番