1Password Environments MCPは"Codex専用"ではない — WindowsのClaude Codeで動かすまで

背景

2026年5月20日、1Passwordが「1Password Environments MCP Server for Codex」を出した。 AIコーディングエージェントがDBやAPIを操作するにはシークレット（認証情報）が要るが、現状は.envファイルやリポジトリへのハードコーディングが多く、流出リスクと監査の穴になっている。このMCPサーバーはシークレットを1Password側に置いたまま、タスクごとに最小スコープで発行し、値をAIモデルのコンテキストウィンドウの外に保つ、という設計になっている。

ニュース記事だけ読むと「OpenAIのCodex向け」に見える。では、Claude Codeでは使えないのか。

結論

「for Codex」は製品名とマーケティングの話で、実体は1Passwordデスクトップアプリに同梱される汎用のローカルMCPサーバー。公式ドキュメントにも「その他のMCPクライアント」向けの登録手順があり、Claude Codeからも使える
ただしWindowsのMicrosoft Store（MSIX）版1Passwordには罠がある。公式ドキュメントが案内するパッケージ内のEXEパスを登録しても、MSIXの起動保護でアクセス拒否になり起動できない
EXEと依存DLLをパッケージ外へコピーすれば起動する。1Passwordの自動更新でパスが変わっても壊れないよう、起動時にバージョンを照合して再コピーするラッパーを作り、Claude Codeに登録して接続確認まで通した
追記（同日）: 接続後の authenticate はWindowsのproduction版アプリでは通らない。ローカルMCPサーバー機能自体が未解禁で、Labsのトグルがグレーアウトしている。アカウント側のフラグは有効で、ベータチャンネルでは対応が進んでおり、productionへの解禁待ち

"Codex専用"かどうかの確認

公式ドキュメント（2026-07-02時点。ベータ中のため記述は変わりうる）を見ると、セットアップ手順はCodex向け（Mac/Linux）とKiro向け（Mac）に加えて、「その他のMCPクライアント」向けが用意されている。

To manually configure the 1Password MCP server, follow your MCP client's instructions to add a local MCP server. Enter the path for your platform as the command

つまり「使っているMCPクライアントの手順でローカルMCPサーバーとして登録すればよい」ということで、stdioのローカルMCPサーバーを登録できるクライアントなら何でも対象になる。 Claude Codeなら claude mcp add で登録できる。

プラットフォーム別のバイナリパスは次のとおり。

プラットフォーム	パス
Mac	`/Applications/1Password.app/Contents/MacOS/onepassword-mcp`
Linux	`/opt/1Password/onepassword-mcp`
Windows	インストール方法により異なる

Windowsについては、Store/MSIX版の場合は次のPowerShellコマンドでパスを取得せよ、と注釈にある（同じく2026-07-02時点の記述）。

(Get-AppxPackage -Name "AgileBits.1Password").InstallLocation + "\onepassword-mcp.exe"

手元の環境（Store版 8.12.26.40）で実行すると、確かにパッケージ内に onepassword-mcp.exe が存在した。

C:\Program Files\WindowsApps\Agilebits.1Password_8.12.26.40_x64__amwd9z03whsfe\onepassword-mcp.exe

ここまでは公式ドキュメントどおり。問題はここからだった。

Windows Store版の罠: EXEが起動できない

このパスをそのまま実行すると、アクセス拒否になる。

アクセスが拒否されました。
EXITCODE=5

Git Bash、PowerShell、cmdのどれから起動しても同じだった。

ACLは実行を許可している

ファイルのアクセス権限を疑って icacls で確認したが、BUILTIN\Users に実行権限（X）が付いていた。

onepassword-mcp.exe BUILTIN\Users:(I)(Rc,S,RD,REA,X,RA)

権限はあるのに実行だけ拒否される。原因は別にある。

原因の切り分け: AppExecutionAliasの有無で挙動が分かれる

1PasswordのAppxManifest.xmlを確認すると、実行エイリアス（AppExecutionAlias）が宣言されているのは次の5つだけだった。

1Password.exe
1Password-BrowserSupport.exe
1Password-LastPass-Exporter.exe
op-ssh-sign.exe
op-ssh-sign-wsl.exe

onepassword-mcp.exe は宣言されていない。

宣言の有無が本当に分かれ目なのかを確かめるため、同じディレクトリ内で対照実験をした。

宣言済みの op-ssh-sign.exe をパッケージディレクトリから直接起動 → 起動する（引数不足のusageエラーが返る＝プロセス起動自体は成功）
未宣言の onepassword-mcp.exe を同じディレクトリから起動 → アクセス拒否

ディレクトリもACLも同じ条件で、エイリアス宣言の有無だけが挙動を分けた。 MSIXパッケージ内のEXEは、マニフェストで宣言されていないと外部プロセスから直接起動できない、という整理が観察事実と合う。

結果として、Store版の1Passwordは、公式ドキュメントがStore版向けにパス取得コマンドまで案内しているにもかかわらず、現バージョン（8.12.26.40）ではそのパスを外部から起動できない。

回避策: パッケージ外へコピーすれば起動する

ACL上は読み取りも実行も許可されているので、EXEと依存DLLを普通のフォルダにコピーしてみた。

cp onepassword-mcp.exe op_sdk_ipc_client.dll op_sdk_lib_core.dll op_windows_vbs_crypt.dll <コピー先>/

コピーしたEXEは起動した。 MCPのinitializeリクエストをstdinに流すと、正常な応答が返ってくる。

{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-06-18",
 "serverInfo":{"name":"rmcp","version":"1.1.0"}, ...}}

サーバーのinstructionsには、次の注意書きが入っていた。

Note: Features like local .env file destinations (locally mounted .env files) are only supported on macOS and Linux.

ローカル.envファイルとしてマウントする機能（シークレットを実行時に注入する経路）はmacOS/Linux限定。 Windowsで使えるのはEnvironmentの作成・一覧・リネーム、変数名の一覧、変数の追加までで、シークレットの値そのものは設計上MCPクライアント側に渡さない。

恒久セットアップ: 更新に追従する自動同期ラッパー

MSIXのパッケージパスはバージョン番号入りなので、1Passwordが自動更新されるとコピー元のパスが変わる。一度コピーして終わりにすると、更新のたびに壊れる。そこで、起動のたびにインストール済みバージョンを照合し、変わっていたら再コピーする同期スクリプトを挟むことにした。

ファイルは %USERPROFILE%\.claude\mcp\1password\ に2つ。

sync-onepassword-mcp.ps1（同期スクリプト）

$ErrorActionPreference = 'Stop'

$pkg = Get-AppxPackage -Name 'AgileBits.1Password'
if (-not $pkg) {
    [Console]::Error.WriteLine('[sync-onepassword-mcp] 1Password (Store版) が見つかりません')
    exit 1
}

$binDir  = Join-Path $PSScriptRoot 'bin'
$verFile = Join-Path $binDir 'version.txt'
$exe     = Join-Path $binDir 'onepassword-mcp.exe'

$cached = if (Test-Path $verFile) { (Get-Content $verFile -Raw).Trim() } else { '' }

if ($cached -eq $pkg.Version -and (Test-Path $exe)) {
    exit 0
}

New-Item -ItemType Directory -Force -Path $binDir | Out-Null
Copy-Item (Join-Path $pkg.InstallLocation 'onepassword-mcp.exe') $binDir -Force
Copy-Item (Join-Path $pkg.InstallLocation 'op_sdk_*.dll') $binDir -Force
Copy-Item (Join-Path $pkg.InstallLocation 'op_windows_*.dll') $binDir -Force -ErrorAction SilentlyContinue
Set-Content -Path $verFile -Value $pkg.Version -NoNewline

[Console]::Error.WriteLine("[sync-onepassword-mcp] synced version $($pkg.Version)")
exit 0

onepassword-mcp.cmd（Claude Codeに登録するランチャー）

@echo off
rem 1Password Environments MCP Server launcher (registered in Claude Code)
rem 1) Sync latest onepassword-mcp.exe from the MSIX package into bin/ (keep stdout clean for MCP)
rem 2) Launch the synced exe, passing stdio through to the MCP client
powershell -NoProfile -File "%~dp0sync-onepassword-mcp.ps1" 1>nul
if not exist "%~dp0bin\onepassword-mcp.exe" (
    echo [onepassword-mcp.cmd] bin\onepassword-mcp.exe not found. Sync failed - check execution policy or 1Password install. 1>&2
    exit /b 1
)
"%~dp0bin\onepassword-mcp.exe" %*

ポイントは3つ。

stdoutを汚さない: stdioベースのMCPはstdoutがプロトコル専用線なので、同期スクリプトの出力は 1>nul で捨てる。ログはstderrに書く（MCPクライアントはstderrをログとして拾ってくれる）
同期失敗時はEXEを起動しない: 同期が一度も成功していない状態で起動に進むと、存在しないEXEを叩いて分かりにくいエラーになる。EXEの存在確認を挟み、無ければstderrにログを出して終了する
バッチのコメントはASCIIで書く: 最初は日本語コメントを書いていて、ハマった。UTF-8で保存したバッチをcmdがCP932として解釈し、コメント行の一部を壊れたコマンドとして実行しようとしてエラー行を吐く。バッチファイルの日本語コメントは事故のもとなので、英語にした

なお、powershell -File での.ps1実行はPowerShellの実行ポリシーに従う。ポリシーが Restricted（Windowsクライアントの既定）の環境では「このシステムではスクリプトの実行が無効になっているため…」で同期が失敗するので、その場合は Set-ExecutionPolicy -Scope CurrentUser RemoteSigned を設定するか、ランチャー側を powershell -NoProfile -ExecutionPolicy Bypass -File ... に変える。

Claude Codeへの登録

claude mcp add --scope user 1password -- cmd /c %USERPROFILE%\.claude\mcp\1password\onepassword-mcp.cmd

--scope user にしたのは、シークレット管理が特定プロジェクトに紐づかないため。登録後のヘルスチェックも通った。

1password: cmd /c ...\onepassword-mcp.cmd - ✔ Connected

ツールは6つ生えてくる。

ツール	役割
`list_environments`	Environmentの一覧
`create_environment`	Environmentの作成
`rename_environment`	Environmentのリネーム
`list_variables`	環境変数名の一覧
`append_variables`	環境変数の追加
`authenticate`	1Passwordデスクトップアプリ経由の認証

authenticate検証（同日追記）: Windows production版は機能未解禁だった

同日、Claude Codeから authenticate を実行して認証まで通るかを検証した。結果は失敗。ただし原因は環境設定のミスではなく、Windowsのproduction版アプリがローカルMCPサーバー機能をまだ解禁していないことだった。切り分けの過程を記録する。

エラーメッセージと実態が食い違う

authenticate を呼ぶと、次のエラーが返る。

MCP error -32603: 1Password desktop app is not running.
Please open 1Password and try again.

だが1Passwordアプリは起動している。プロセス一覧には 1Password 本体とBrowserSupport、そして各セッションが起動した onepassword-mcp が並んでいた。

MCPバイナリ側のログ（%LOCALAPPDATA%\1Password\logs\MCP\）を見ると、実際に起きていることが分かる。

INFO  MCP -- authenticating session with scopes
INFO  MCP -- IPC unavailable, attempting to launch 1Password
ERROR op-oph-launcher -- could not find 1Password to launch
ERROR MCP -- IPC still unavailable after launching 1Password
ERROR MCP -- authentication request failed

「アプリが起動していない」のではなく、バイナリがアプリ側のIPCリレーに接続できていない。なお could not find 1Password to launch は、パッケージ外にコピーしたEXEが自分の由来を Installer=Unknown と認識するせいでアプリの場所を解決できないという、ラッパー方式の副作用も混ざっている。ただし主因は次のとおりIPCリレーの不在だった。

IPCリレーはLabsの実験機能で、トグルが有効化できない

MCPサーバー同梱の getting-started ドキュメントに、記事執筆時点で見落としていた前提が書かれていた。ローカルMCPサーバーは1Password Labsの実験機能で、アプリの Settings → 1Password Labs → MCP Server で「Enable local MCP server」をONにすると、アプリがIPCリレーを起動する。バイナリはそのリレーに接続する仕組みで、トグルがOFFのままではどう登録しても認証は通らない。

ところが手元のWindows（Store版 8.12.26.40）では、このトグルがグレーアウトしていて操作できない。

切り分け: フラグは有効、アプリ側が未解禁

トグルが無効化される原因を順に切り分けた。

アカウント側のフィーチャーフラグは有効。getting-startedには「ai-local-mcp-server フラグがアカウントで有効であること」が条件とあるが、ローカルDBを確認すると ai-local-mcp-server{"enabled":true,"protected":false} が記録されていた。フラグ待ちではない
アプリはMCP統合を無効と判定している。アプリ本体ログの起動時に MCP integration is disabled in settings が出る。settings.jsonにはMCP関連キーが存在せず、トグルは一度も保存に至っていない
Windows安定版のリリースノートにはMCPサーバーの言及が皆無。一方、ベータチャンネルでは 8.12.28-17（2026-07-01）で「バンドルされたMCPバイナリを絶対パスの代わりに起動できるようになった」「CLI・SDK・MCPクライアント統合を Settings → Developer に集約」というMCP関連の変更が入っている

つまりproduction 8.12.26.40は、MCPバイナリとLabsのUIだけが先行して同梱され、機能本体はベータチャンネルで開発中という状態だった。トグルのグレーアウトはその表れで、ユーザー側で解除する手段はない。

含意: MSIX起動拒否問題は1Password側が公式に解消しにきている

ベータの「バンドルされたMCPバイナリを起動できるようになった」という変更は、本記事で回避したMSIXの起動拒否問題そのものへの対処と読める。この変更がproductionに降りてくれば、EXEをパッケージ外へコピーする自動同期ラッパーは不要になる見込みだ。

残っている確認事項

Windows production版でローカルMCPサーバーが解禁されたら、Labsトグル有効化 → authenticate → list_environments → list_variables を再検証する
解禁後、ベータで入った「バンドル済みバイナリの起動対応」がproductionにも入っていれば、自動同期ラッパーを廃止して公式パス直接登録に切り替える
ローカル.envファイルのマウント（シークレット注入経路）はmacOS/Linux限定のまま。Windowsでの提供有無は引き続きウォッチする

まとめ

1Password Environments MCP Serverは"Codex専用"ではなく、Claude Codeを含む任意のMCPクライアントから使える設計になっている
ただしWindows Store（MSIX）版は、公式ドキュメントの案内どおりにパッケージ内のEXEパスを登録しても、AppExecutionAlias未宣言のため起動できない。ACLを見ても原因は分からず、AppxManifestを見ると分かる
EXEと依存DLLをパッケージ外へ同期するラッパーを挟めば動く。バージョン照合付きにしておけば1Passwordの自動更新にも追従する
ただし接続できるのはハンドシェイクまで。認証（authenticate）はアプリ側のIPCリレーが前提で、Windowsのproduction版（8.12.26.40）はLabsのトグルが無効化されており解禁待ち（2026-07-02時点）。アカウント側のフラグは有効なので、待てば使えるようになる見込み
ベータチャンネル（8.12.28-17）ではバンドル済みMCPバイナリの起動対応が入っており、productionに降りてくればこのラッパー自体が不要になる。それまでのつなぎとして使う