トークンは有効だった。それなのに、ヘッドレス・エージェントは401エラーを返した。
コード経由でClaudeを呼び出す2つの小さなツールを作成しました。一つはコミットメッセージを生成するもの、もう一つはプロフィールを更新するものです。
コードは完璧に見えました。環境変数からAPIキーを取得し、Anthropic APIへ生のHTTPSリクエストを送信し、JSONレスポンスを解析する。
しかし、毎回401エラーで失敗しました。
問題はコードではありませんでした。問題は認証方法にありました。
私は生のAPIキーを使用していませんでした。サブスクリプションを通じてClaude Codeを使用しています。これはClaude CLI経由のOAuthを使用します。これは、スクリプトが想定していたものとは異なるシステムでした。
環境変数のAPIキーに、古い値、あるいは空の値が入っていました。スクリプトは値が存在することを確認し、それが有効であると判断しました。その結果、誤った種類の認証情報を使用してリクエストが送信されてしまったのです。
解決策は簡単でした。直接APIを呼び出すのをやめ、代わりに、すでに有効なセッションを持っているCLIを使用するようにスクリプトに指示しました。
旧方式：
urllib を使用してAPIキー付きのリクエストを送信する。
新方式：
subprocess を使用して "claude" コマンドを直接実行する。
CLIがセッション、トークン、および有効期限をすべて処理してくれます。
この間違いは、ヘッドレス環境では危険です。人間であればターミナルでエラーを確認できますが、cronジョブやCIパイプラインはサイレントに失敗します。数日間気づかないこともあるでしょう。
他の場所でも、同じパターンを目にすることでしょう：
- ツールがパーソナルアクセストークンを探しているが、システムはOIDCを使用している。
- スクリプトがAWSキーを読み取っているが、システムはIAMロールを使用している。
トークンは存在する。トークンの形式も正しい。基本的なチェックはパスするが、メカニズムが間違っている。
これを避けるために、以下のルールに従ってください：
- コードを書く前に、環境が対話的にどのように認証を行うかを確認してください。単にAPIドキュメントに従うだけでは不十分です。
os.environを過信しないでください。値が存在していても、それが古いか間違っている可能性があります。- CLIツールが認証を処理してくれる場合は、それを使用してください。認証ロジックを自分で再構築するのではなく、CLIをシェル経由で呼び出しましょう。
- 401エラーが発生した場合は、リクエストのコードを変更する前に、認証情報のパスを確認してください。
Source: https://dev.to/enjoy_kumawat/the-token-was-valid-my-headless-agent-401d-anyway-3bgl
Optional learning community: https://t.me/GyaanSetuAi