#oauth

まず、この症状に当てはまるかを見ます。`claude --chrome` や Claude in Chrome の side panel で、接続が一度つながったように見えてもすぐ切れ、再接続のたびに `OAuth token forbidden (403) — missing scope, org access, or network not allowed by org` が返るなら、今回の issue 群とかなり近いです。報告されているのは [#108547](https://github.com/anthropics/claude-code/issues/108547) と [#108765](https://github.com/anthropics/claude-code/issues/108765) です。どちらも、見た目は接続できているのに bridge 側で 403 が返り、結果として切断が繰り返されています。 報告内容だけを見ると、原因はローカルの壊れたトークンより、アカウントや組織側の認可条件にあるようです。`#108547` では、WebSocket はしばらく

最初に思ったのは、「OAuth の面倒くさいところを、ちゃんとユーザー体験に落とし込もうとしているな」ということでした。 redirect URI の扱いって、ふだんは「セキュリティ上の制約だから仕方ない」で終わりがちですが、この記事はそこをもう少し丁寧にほどいています。管理者が一括で allowlist を持つだけだと、既存の大手クライアントには優しいけれど、個人が作った agent や週末に書いた MCP client は締め出される。逆に緩くすると phishing の穴になる。この二択の息苦しさは、読んでいてすごく納得感がありました。 面白かったのは、「信頼」をサーバー側の固定設定ではなく、サインイン時にそのユーザーが決める、という切り分けです。 これ、言われてみれば自然ですが、実装に落とすのは簡単ではなさそうです。登録時点では「誰がこの client を使うのか」がまだ分からないので、そこではゆるく受けて、authorize の段階で初めて“この人はこの host を信頼しているか”を見る。OAuth の危険なところって、たいてい「見た目は正しいのに、実は別の場所へ code

What surprised me here is not that OAuth can be bent into a phishing hole. That part is old news. What surprised me is how cleanly the article argues that the usual “just whitelist the client” answer is the wrong layer for MCP, because the thing you actually want to trust is not a brand or an app registration in the abstract, but a specific redirect destination for a specific user at a specific moment. That feels like the right instinct. A lot of these systems collapse because they try to make t

このエラーは、Claude Code から MCP や連携先を呼び出した瞬間に出ることがあります。今回の issue 群では、見え方が少し違っていました。 ひとつは、`/mcp` では Gmail / Google Calendar / Google Drive が「接続済み」のように並ぶのに、実際に使おうとすると `requires re-authorization (token expired)` になるケースです。報告者は、claude.ai ではそれらが未接続として表示され、`Connect` ボタンが出ていると書いています。Claude Code 側では同じものが接続済みのように見えてしまうため、状態表示が紛らわしい、という問題でした。これが [#76010](https://github.com/anthropics/claude-code/issues/76010) です。 もうひとつは、Calendly の MCP で認証がその場で失敗するケースです。`/mcp` から `calendly` を選んで `Authenticate` しても、`claude mcp log

このエラーを検索してたどり着くケースは、少なくとも今回の issue では 2 つの顔があります。ひとつは、デスクトップアプリを閉じていないのに、日中に何度も再認証を求められるケースです。もうひとつは、VS Code 側でいったん再ログインできたのに、古い認証エラー表示が残り続けるケースです。 前者は [#98693](https://github.com/anthropics/claude-code/issues/98693) で、macOS のデスクトップアプリと、同じアカウントを使う headless な `claude --print` 呼び出しが同時に走っている状況でした。報告では、scheduled な macOS LaunchAgents が 11 本あり、同じアカウントに対して独立した `claude --print` を投げています。Keychain の `Claude Code-credentials` の更新時刻が 2026-10-01 11:00:04 UTC、つまり 7:00:04 AM と一致している、とも書かれています。報告者は、このタイミングの一致が偶然

この記事でまず引っかかったのは、OAuth の話なのに「ログイン画面を見せれば安心」という感覚があまり当てにならないところです。ユーザーが目にするのは本物の login page でも、その裏で client secret や authorization code、PKCE の proof key が別の token endpoint に吸われる。見た目が正しいことと、通信の行き先が正しいことは別物だと、あらためて突きつけられた感じがしました。 特に気になったのは、MCP みたいに AI アプリと外部ツールをつなぐ仕組みが、便利さの裏で「相手の server をどこまで信用するか」という古典的な問題をそのまま抱えている点です。しかも machine-to-machine の provider だと、人が操作しなくても成立してしまう。これ、単なる実装ミスというより、AI 周辺の連携機能が増えるほど攻撃面も増える、という嫌な予感を強める話だと思います。 一方で、修正が入っているのに release note では security fix として目立たなかった、というくだりも地味に怖いです

What jumps out here isn’t the bug itself so much as the shape of it. An official SDK for an authentication-heavy protocol let a server redirect an OAuth exchange to a place it shouldn’t trust. That’s the kind of mistake that looks small in code and huge in blast radius. If I were evaluating MCP client integrations right now, I’d be less interested in the CVSS number and more interested in whether any app I care about ever assumes “the server told me where to log in” is a safe sentence. The annoy

この症状は、少なくとも今回の issue 群では 「Remote Control の起動や再接続の途中で、資格情報の取得が失敗している」 形で報告されています。読者が自分のケースかどうかを先に切り分けるなら、次の2つに当てはまるかを見るのが早いです。 ひとつは、起動直後や cold start で Remote Control を有効にしたときに、ステータスバーへ `Remote Control failed · Remote credentials fetch failed — see debug log` のような表示が出るケースです。[#78598](https://github.com/anthropics/claude-code/issues/78598) では、`"remoteControlAtStartup": true` を有効にした状態で、OAuth アクセストークンの更新より先に remote bridge が最初の API 呼び出しを行い、`POST /v1/code/sessions` と `/bridge` が **HTTP 401 Authentic

Claude Code から Claude in Chrome 拡張を使おうとして、`claude.ai/oauth/authorize` まで進んだのに、Authorize を押した直後に `Authorization failed` で止まる。今回の issue 群は、まさにその症状に当てはまります。 報告されているのは、Claude in Chrome extension の OAuth authorization が、認可画面で Authorize を押した直後に `Authorization failed — This isn't working right now` になる、というものです。#69051 では、拡張機能をインストールし、Claude Code 側で Claude in Chrome connector を有効にし、ブラウザで認可しても失敗する手順がそのまま書かれています。#95958 でも、別環境で同じ失敗が再現したとされています。参照できる issue は [#69051](https://github.com/anthropics/claude-code

いちばん引っかかったのは、MCPそのものより「ちゃんと運用すると、急に話が現実になる」という空気でした。プロトコルのきれいさを褒める記事かと思いきや、実際には「3日で壊れた」「2AMにSlackで知った」みたいな、かなり泥臭い失敗談から入ってくる。そこがよかったです。AIまわりの話って、デモの気持ちよさに寄りがちですが、この記事は最初から“壊れる前提”で読ませにきている。 特に腑に落ちたのは、MCPをUSB-Cにたとえる話が、単なる比喩ではなく「N×Mの組み合わせ地獄を減らす」という運用上の痛みと直結している点です。LLMとツールの接続が増えるほど、個別実装の継ぎはぎは本当にきつくなる。ここでJSON-RPCという共通の会話形式に寄せるのは、地味だけどかなり強い発想だと思います。派手な機能より、まず“壊れにくい共通語”を作る。AI時代のインフラっぽさがある。 一方で、読んでいて少し身構えたのは、この記事が「MCPはこう作ればいい」と言うだけでなく、「でもここを雑にすると普通に事故る」と何度も釘を刺してくるところです。特にOAuth 2.1やstateless scalingの話は、きれ

まず、この症状に当てはまるかどうかはかなりはっきりしています。issue #66332 では、Android 端末から GitHub Codespaces を使っていると、Claude Code の OAuth が `localhost:PORT/callback` に飛び、その先に接続できず `ERR_CONNECTION_REFUSED` になると報告されています。`claude setup-token` でも同じ localhost リダイレクトで失敗した、と書かれています。別件の #70415 では、ブラウザベースの Codespace（`.github.dev`）で `CLAUDE_CODE_OAUTH_TOKEN` 環境変数が無視され、ログインメニューから Claude account を選ぶとやはり localhost の OAuth callback で `ERR_CONNECTION_REFUSED` になった、という報告でした。 つまり、少なくともこの 2 件で共通しているのは、「ブラウザから localhost に戻る認証経路が使えない環境で止まる」ことです。An

この症状は、少なくとも issue [#81937](https://github.com/anthropics/claude-code/issues/81937) と [#93521](https://github.com/anthropics/claude-code/issues/93521) で報告されています。どちらも「OAuth のセッションが期限切れで、更新できない」という同じ文言に見えますが、出方が少し違います。 ```text Failed to authenticate: OAuth session expired and could not be refreshed ``` ```text Failed to authenticate. API Error: 401 {"type":"error","error":{"type":"authentication_error","message":"OAuth access token has been revoked."},"request_id":null} ``` 一方 [#93521](https://gith

この症状は、`claude remote-control` の登録段階で止まり、401 とともに `Missing Authorization header` と出るケースです。今回の報告では、[`#83958`](https://github.com/anthropics/claude-code/issues/83958) と [`#83976`](https://github.com/anthropics/claude-code/issues/83976) のどちらも、登録フェーズで同じエラーに落ちています。 まず切り分けたいのは、「単に認証が切れている」のか、「Authorization ヘッダー自体が送られていない」のかです。issue #83958 では、当日の新しく発行された OAuth トークンでは Authorization ヘッダーが送られず、同じ CLI バージョンでも朝は古いトークンで送れていた、という観察が書かれています。つまり、少なくともその報告では、ユーザー操作のミスというより CLI 側の挙動に見えます。 issue #83976 では、同じアカウ

最初に思ったのは、これは地味だけどかなり筋がいい変更だな、ということだった。OAuthの同意画面って、結局のところ「全部許すか、全部やめるか」になりがちで、特にagentやMCP serverみたいにやたら広い権限をまとめて欲しがる相手には、ユーザー側が白か黒かで判断するしかなかった。そこに「この権限は外してよい」と開発者が印を付けられるのは、かなり現実的だと思う。 面白いのは、これがユーザーの自由を広げる話に見えて、実際には開発者の責任を少し増やすところだ。ユーザーが optional scope を外したら、アプリは「まあ動くはず」では済まない。返ってきた token の scope を見て、足りない機能はちゃんと落とす必要がある。つまり、同意画面で頑張るだけではなく、その後の振る舞いまで設計に入れないといけない。ここは、表向きの UX 改善よりもずっと実装の癖が出る部分だと思う。 それにしても、agent のための権限設計ってやっぱり難しい。人間なら「このアプリは在庫を見るだけ」と説明されれば想像できる。でも agent は、将来その権限をどう使うかを全部まとめて請求してくる。読

What caught my attention here is not the feature itself, but the fact that Cloudflare is finally admitting something the OAuth UX has always kind of pretended away: consent is usually too blunt for agentic software. If an MCP server asks for a bundle of scopes, a human is asked to bless the whole bundle, even when only one or two parts are actually relevant to the task. That’s a bad fit for agents, and honestly it’s been a bad fit for a while. I think the interesting move is that Cloudflare isn’

まず、この症状に当てはまりやすいのは、ブラウザが開いた先で `Invalid OAuth Request — Missing redirect_uri parameter` と表示され、ログイン処理が最後まで進まないケースです。Issue では、`claude auth login` のあとにブラウザが `claude.ai/cai/oauth/authorize` 側へ飛び、認証完了後に `https://claude.com/cai/oauth/authorize` 付近で同じ文言が出る流れが報告されています。`claude setup-token` や Console Anthropic の “Continue with Claude Pro” でも再現した例がありました。([#91911](https://github.com/anthropics/claude-code/issues/91911)) 同じ症状は、別の報告でも見え方がかなり近いです。`/login` の直後にブラウザで OAuth エラーになり、しかも別マシンの別ユーザーでも同じエラーが出た、という内容でした。

まず切り分けたいのは、MCP 接続が本当に未認証なのか、それとも「未認証だと言われているだけ」なのかです。今回の症状は後者として報告されています。`claude.ai` の OAuth connector がすでに認証済みで、同じセッション内でツール呼び出しも成功しているのに、セッション開始時の system reminder に「requires authentication before their tools can be used」と出て、さらに > “Tell the user that these servers need to be authorized … and that the capability is unavailable until they do.” という指示まで載る、という内容です。該当する issue は [#76320](https://github.com/anthropics/claude-code/issues/76320) と [#77534](https://github.com/anthropics/claude-code/issues

このエラーが出るのは、Claude Code が OAuth 認証で進もうとして、所属組織側でそれが許可されていないときです。少なくとも issue の報告では、`Your organization has disabled Claude subscription access for Claude Code` という案内とあわせて `OAuth authentication is currently not allowed for this organization.` が返っています。該当する報告は [#63685](https://github.com/anthropics/claude-code/issues/63685) と [#63886](https://github.com/anthropics/claude-code/issues/63886) です。 まず見分けたいのは、自分が「個人の Pro 契約を持っているのに弾かれている」のか、それとも本当に組織管理下のアカウントとして扱われているのか、です。[#63886](https://github.com/anthro

Claude Code を使っていて `401` の `authentication_error` が急に出るなら、少なくとも今回集まっている報告では「認証が壊れた」というより、セッション中に OAuth token の期限切れや再認証が必要になっているケースが中心でした。 ただし、同じ `authentication_error` でも issue は 2 系統あります。 ひとつは、[#18225](https://github.com/anthropics/claude-code/issues/18225) のように、長く使っていたセッションで突然 401 が出始め、`/login` を何度も求められるパターンです。報告者は「months 使っていて、today から始まった」と書いています。エラーメッセージは次のとおりです。 ```text API Error: 401 {"type":"error","error":{"type":"authentication_error","message":"OAuth token has expired. Please

MCP（Model Context Protocol）は、AIエージェントが外部のツールやファイル、サービスにアクセスするための共通ルールだ。ざっくり言うと、「AIに何をどう頼むか」を標準化するための通信規格である。 今回の元記事が面白いのは、単なる機能追加の話ではなく、MCPの骨格そのものが変わったと指摘しているところだ。いちばん大きいのは、これまで前提だった「セッションを持ち続ける」方式をやめたこと。これでMCPは、かなりHTTPらしい、軽くて扱いやすい形に寄ってきた。 2026-07-28仕様で、MCPはセッション前提の stateful な設計をやめた これにより、sticky session や共有Redisのような面倒な運用が減る OAuth / OIDC の安全性が強化された tool list や prompt list などにキャッシュ期限を持たせられるようになった Tasks は正式な extension として整理され、長い処理を扱いやすくなった 主要SDKはすでに対応しており、MCPはかなり大規模に使われている 元記事の中心はここ

Model Context Protocol（MCP）の世界で、かなり実務的で、しかも地味に効くアップデートが正式版になりました。 その名も Enterprise-Managed Authorization（EMA）。ざっくり言うと、「社内のID管理基盤でMCPサーバーへのアクセスをまとめて管理できる仕組み」です。 MCPは、AIアシスタントや開発ツールが外部サービスとつながるための共通規格として広がってきました。ただ、企業で使うとなると、思った以上に面倒が多い。サーバーごとにOAuthの許可画面が出て、社員が一人ずつポチポチ承認していく。これ、個人利用ならまだしも、組織運用だとかなりしんどいです。今回のEMAは、その“しんどさ”をかなり正面から潰しにいっています。 Enterprise-Managed Authorization（EMA）がstableになった 企業はIdP（Identity Provider）でMCPサーバーへのアクセスを一元管理できる ユーザーは初回ログイン時に自動で接続され、サーバーごとのOAuth許可が不要になる アクセス制御は

Cloudflareが、self-managed OAuth をすべての開発者に開放しました。 これ、地味に見えてかなり大きなニュースです。というのも、OAuthは「外部アプリに、どこまで何を許可するか」を安全に扱うための仕組みで、SaaS連携や社内ツール、いま流行りのagentic toolまで、あちこちで土台になっているからです。 Cloudflareは自社のAPIを使って自動化やCI/CD、各種連携を作れる強いプラットフォームですが、これまでは第三者向けのOAuthは一部の手動オンボーディング済み統合に限られていました。 つまり、誰でも自由に「Cloudflare用のOAuthアプリ」を作れる状態ではなかったわけです。 その制限が外れた。ここが本題です。 CloudflareのOAuthが、限られた提携先だけでなくすべての開発者に開放された API token中心の運用よりも、権限を細かく分けやすく、取り消しもしやすい その裏側では、OAuthエンジンの大規模アップグレードをかなり慎重にやっていた データベース移行は派手。1億件超の更新・挿入が走っ

For Claude and Claude Code developers, this is a big deal because it tackles one of the least glamorous but most painful parts of real-world AI tooling: auth. If you’ve ever watched an enterprise deployment get bogged down by repeated consent prompts, inconsistent access rules, or awkward personal-vs-work account boundaries, this announcement is aimed straight at that mess. The Model Context Protocol’s Enterprise-Managed Authorization (EMA) extension is now stable. EMA lets organizations central

「送信」を押したのにメールが送信トレイ（Outbox）に居座ったまま動かない——この古典的なトラブルは、2026年現在も現場で最も多いメール障害のひとつだ。ただし原因の比重は1年前から大きく変わった。従来の「オフライン設定」「大容量添付」「ポートブロック」に加えて、2025〜2026年はプラットフォーム側の構造変化が新たな送信不能要因として浮上している。 本稿はエンジニア／情シス担当者の視点で、(1) まず切り分けるべき診断フロー、(2) 2026年特有の2大変化、(3) 恒久対策、の順に整理する。 --- 2026年のトラブルシュートで最初に確認すべきはどのOutlookを使っているかだ。両者は送信処理のアーキテクチャがまったく異なる。 classic Outlook（従来のデスクトップ版） — ローカルに `.ost`/`.pst` を持ち、送信トレイ → 送信処理 → 送信済みという明示的なキューを経由する。「送信トレイに残る」のはこちら特有の症状。 新しいOutlook（new Outlook for Windows） — 実体は