はじめに
最近、CodexからNotion MCPを利用して研究メモや日報を整理する環境を構築していました。
やりたかったことはシンプルです。
- 壁打ち内容をNotionへ蓄積
- CodexとNotionを連携
- Skillsを使って日報やナレッジ抽出を自動化
- 後から検索・整理しやすくする
しかし、Notion MCPを接続したところ、
Codexを起動するたびにNotionの認証確認が走る
という問題に遭遇しました。
調査したところ、原因はNotion MCPそのものではなく、接続方式にありました。
本記事では、
- CodexでNotion MCPを設定する方法
- Direct接続とmcp-remote経由接続の違い
- 毎回認証が発生していた原因
- 解決方法
をまとめます。
MCP設定ファイルについて
Codexでは、MCPサーバーの設定を以下のファイルで管理します。
~/.codex/config.toml
macOSの場合の例：
/Users/<ユーザー名>/.codex/config.toml
ファイルが存在しない場合は作成します。
mkdir -p ~/.codex
touch ~/.codex/config.toml
今回紹介する2つの接続方式は、どちらもこのファイルへ記述します。
Notion MCPの接続方法は2種類ある
Notion MCPをCodexへ接続する方法は大きく2種類あります。
1. Direct接続（公式推奨）
まず、~/.codex/config.toml を編集します。
[mcp_servers.notion]
url = "https://mcp.notion.com/mcp"
認証は以下のコマンドで行います。
codex mcp login notion
構成としては、
Codex
↓
Notion MCP
となります。
この方式では、OAuth認証情報の管理をCodex自身が行います。
期待される挙動は以下です。
- 初回のみOAuth認証
- 以降は保存済み認証情報を利用
- 必要に応じてツール利用確認のみ表示
向いているケース
- 公式推奨の構成を使いたい
- 設定をシンプルにしたい
- 認証管理をCodexに任せたい
- 問題発生時の切り分けを容易にしたい
2. mcp-remote経由
以前の私の設定は以下でした。
こちらも同じく ~/.codex/config.toml に記述します。
[mcp_servers.notion]
startup_timeout_sec = 60
command = "npx"
args = ["-y", "mcp-remote", "https://mcp.notion.com/mcp"]
構成としては、
Codex
↓
mcp-remote
↓
Notion MCP
となります。
この方式では、Codexは直接Notion MCPへ接続せず、mcp-remote が中継役になります。
そのため、
- Codex
- mcp-remote
の両方が認証処理に関与します。
向いているケース
- 独自MCP構成を利用している
- リモートMCPサーバーを統一的に扱いたい
- MCP周りをカスタマイズしたい
なぜ毎回認証されたのか
当初は、
Notion MCPは毎回接続確認が必要な仕様なのかな？
と思っていました。
しかしログを確認すると、
https://mcp.notion.com/authorize?...
がCodex起動時に毎回表示されていました。
つまり実際には、
Codex起動
↓
mcp-remote起動
↓
OAuth開始
↓
認証確認
という流れになっていました。
つまり、Notion MCPの仕様というよりも、mcp-remote 経由の構成によって認可フローが毎回開始されていた可能性が高い状態でした。
認証保持の責任が違う
重要なのはここです。
| 接続方式 | OAuth保持主体 |
|---|---|
| Direct接続 | Codex |
| mcp-remote経由 | Codex + mcp-remote |
Direct接続では、
Codex
└ OAuth情報保持
となります。
一方、mcp-remote経由では、
Codex
↓
mcp-remote
└ OAuth情報保持
となります。
そのため、
- OAuth再利用
- トークンキャッシュ
- 認証情報管理
に問題が発生した場合、
「Codexの問題なのか」
「mcp-remoteの問題なのか」
の切り分けが難しくなります。
今回の症状は、
- 以前はmcp-remote経由だった
- 認可フロー（/authorize）が起動のたびに開始されていた
- Direct接続へ変更すると改善した
ことから、mcp-remote経由の構成に起因する問題だった可能性が高いと考えています。
解決方法
設定を公式推奨のDirect接続へ変更しました。
[mcp_servers.notion]
url = "https://mcp.notion.com/mcp"
その後、
codex mcp login notion
を実行。
ブラウザで一度認証を行うと、その後は正常に利用できるようになりました。
余談：Operation not permitted が発生した
設定作業中に、
Error: Operation not permitted (os error 1)
というエラーにも遭遇しました。
最初は、
- config.tomlの権限
- 所有者(root)
- chmod
などを疑いました。
しかし実際の原因は、
macOSのプライバシー保護機能（TCC）
でした。
使用していたWarpに対して、
フルディスクアクセス
を許可すると解消しました。
なぜフルディスクアクセスで直ったのか
macOSには通常のUNIXパーミッションとは別に、
- Desktop
- Documents
- Downloads
- iCloud Drive
などへのアクセスを制御する仕組みがあります。
アプリ側の権限が不足していると、
Operation not permitted
が発生します。
今回の場合、
- ~/.codex
- 認証情報
- プロジェクトファイル
へのアクセス時に、Warp側の権限が影響していた可能性があります。
なお、一度許可した後にフルディスクアクセスを解除しても動作したため、認証情報やアクセス許可のキャッシュが影響していた可能性があります。
今後やりたいこと
今回Notion MCPを導入した目的は、単なるメモ保存ではありません。
例えば、
- 壁打ちログを自動で蓄積
- 毎日の日報をSkillsで生成
- 会話ログからナレッジ抽出
- 後から検索しやすい形で整理
といった仕組みを作りたいと考えています。
ChatGPTとの壁打ちは非常に便利ですが、
- 話が広がる
- 後から整理が大変
- コピペが面倒
という課題があります。
Notion MCPとSkillsを組み合わせることで、
会話 → 整理 → 蓄積
の流れを自動化できそうです。
まとめ
今回は、CodexとNotion MCPの連携時に毎回認証確認が発生する問題を調査しました。
結果として、原因はNotion MCPの仕様ではなく、mcp-remote を経由した接続構成にある可能性が高く、公式のDirect接続へ変更することで改善しました。
今後はNotion MCPを活用して、壁打ちログや日報、ナレッジの蓄積を自動化していきたいと考えています。
同じように、
CodexでNotion MCPを使いたいのに毎回認証される
という方の参考になれば幸いです。