プラットフォーム対応

OpenCodex は macOS、Windows、Linux で動作します。大部分の動作は 3 つの OS で共通ですが、一部の機能は OS が提供する仕組みに依存します。このページでは、その違いと理由を説明します。

すべてのプラットフォーム

機能	備考
プロキシ、ルーティング、プロバイダーアダプター	コアランタイムは OS に依存しません。
バックグラウンドサービス	macOS は launchd、Windows は Task Scheduler または WinSW、Linux は systemd ユーザーユニットという 3 種類のネイティブバックエンドがあります。
ブラウザーログイン	OS 固有のハンドラーで開きます。
クライアントの検出	Cursor、Claude Desktop、Kiro、Codex のインストールを OS ごとに検出します。

OS の認証情報ストアに置くプロバイダーキー

ロック解除された OS の認証情報サービスが利用できる場合、3 つのプラットフォームすべてに対応します。macOS では Keychain、Windows では Credential Manager、Linux では libsecret を使います。キーチェーンがロックされている場合やヘッドレスセッションには、利用可能なサービスがありません。OpenCodex は黙って別の保存方法に切り替えず、利用できないことを通知します。保存規則はプロバイダーを参照してください。

macOS のみ

Claude Code の自動接続

ANTHROPIC_BASE_URL と Claude Code 用の設定をセッションに注入する仕組みは、launchd のユーザードメインを使います。他の OS に完全に対応する単一の仕組みはありません。

Linux で考えられる 3 つの方法は、それぞれ異なるプロセスにしか届きません。systemctl --user set-environment は systemd から起動したユニットのみ、~/.profile はログインシェルのみ、~/.bashrc は対話型の非ログインシェルのみです。ユーザーセッション全体を覆う場所はありません。

Windows で相当するのは HKCU\Environment ですが、これは起動ごとではなく永続的です。問題は、再起動時に消える領域にあったベアラートークンを、消えないレジストリハイブへ移すことです。認証情報がディスクに残る期間と読み取り可能な主体が変わるため、移植の前にセキュリティレビューが必要です。

Claude Code に必要なその他の機能は、すべての OS で動作します。同じ環境変数を自分で設定するか、子プロセスに直接渡す ocx claude を実行できます。

インポートと貼り付け

Meta Muse Code

macOS では、muse login の後に Muse Code CLI が保存した API キーを OpenCodex がインポートするため、もう一度用意する必要はありません。

他の OS ではキーの貼り付けを求めます。Meta はネイティブ Windows CLI を提供していません。Linux には CLI がありますが、認証情報の保存場所が確認されていないため、OpenCodex は推測しません。同じキーは Meta の開発者コンソールでも確認できます。貼り付けたキーにも、インポートしたキーと同じ形式検査と Model API に対するライブ検証が適用されます。

Windows に関する注意

Windows サービスは Task Scheduler またはネイティブ WinSW サービスとして動作できますが、両方を同時には使えません。両方の状態が見つかった場合、ocx service repair は処理を拒否します。どちらを意図したか推測すると、2 つのプロキシが同じポートを奪い合う可能性があるためです。

英語以外の Windows では、コンソール出力は UTF-8 ではなくシステムコードページで届きます。OpenCodex はそれに合わせてデコードし、非 ASCII 文字を含むアカウント名も正しく解決します。

機能が使えない場合

OpenCodex はコントロールを黙って無効にせず、実際の理由を示します。お使いの OS で機能を利用できない場合は、不足している仕組みと対応する代替手段がエラーやダッシュボードに表示されます。それが表示されない場合は、報告すべき不具合です。