Windows メモリの増加

一部の Windows ユーザーは、opencodex の背後にある bun プロセスが、長時間のストリーミングセッション中に数ギガバイトの RSS に増加するのを目にします (問題 #314 として報告されています)。このページでは、実際に何が起こっているのか、そしてそれに対して何ができるのかを率直に説明します。

根本原因: アップストリームの Bun ランタイムの問題

opencodex には Bun ランタイム (現在 1.3.14) がバンドルされています。メモリの増加は、プロキシでの JavaScript レベルのリークではなく、アップストリームの既知の Bun の問題によって引き起こされます。

パン問題	状態 (2026-07-23 確認)
#28035 — `fetch()` 受信バックプレッシャーは JS 消費に関係しません。 PR #29831 によって修正されました。どのリリースがそれを搭載しているかは未検証です — バンドルされている 1.3.14 には搭載されていないと想定しています。
#32111 — クライアントが非同期プルストリームを中止するとクラッシュします。 2026 年 6 月 21 日にマージされた PR #32120 を修正。 1.3.14 には存在しないと想定されています。注: このクラッシュは Windows 固有のものではありません (macOS/Linux でも再現されました)。
PR #31654 — `node:net` ソケットハンドルのリーク	上流はまだ営業中

Windows では、#32111 クラッシュを回避するために、opencodex は保守的なコードパスで応答をストリーミングし続ける必要があります。そのパスはバックプレッシャーの問題に最もさらされるパスです。低速または停止したクライアントは、JavaScript がバインドできないネイティブメモリにアップストリームデータをバッファリングしているランタイムを残す可能性があります。

opencodex の現在の対応

制限付きの緩和と可視性 — 修正ではありません。バンドルされた 1.3.14 ランタイムでは、リーク自体は上流の問題のままです。

メモリウォッチドッグ - プロキシは、毎分自身のメモリをサンプリングし、ログに記録します。観測されたメモリが 4 GiB を超えると、レート制限の警告が表示されます。 Windows ワーキングセット/RSS カウンターがコミットされた外部保持を過小報告する可能性があるため、観測されたメモリは RSS、external、および arrayBuffers の最大値になります (これらの合計ではありません)。
ocx doctor — 「メモリ / ランタイム」セクションには サービス が表示されますプロセスの Bun バージョン、RSS、外部/ArrayBuffers カウンター、JS ヒープコンテキスト、およびストリームモードの決定。バンドルされている Bun 1.3.14 ランタイムでは、heapUsed / jscHeap 単独ではリーク識別子ではありません。アプリレベルのリークを割り当てる前に、観察されたメモリを responseState および繰り返しサンプルと比較します。
GET /api/system/memory — 認証済みの同じデータダッシュボードまたはスクリプトの管理 API。 RSS/ヒープ/外部カウンターとともに、プロキシのメモリ内 previous_response_id 継続ストアのスカラー responseState ブロック (エントリ数、シリアル化された合計/最大バイト数、最も古いエントリの経過時間) を報告します。これはさらに成長に起因します。観察された記憶の上昇下での responseState.totalBytes の上昇は会話の保持を指します (長い store:false チェーンはターンごとに再拡張します)。一方、観察された記憶の上昇の下での横ばいの responseState はそのストアから遠ざかることを示します。値はスカラーのみであり、リクエスト本文、トークン、パス、アカウント識別子はありません。また、読み取りには副作用はありません (プルーニングや削除は行われません)。ダッシュボードの メモリ可観測性 カードは同じフィールドをレンダリングし、確認ゲート付き ドレインと再起動 アクションを提供します。現在のアクティブターン数を表示し、アクティブターンを最大 60 秒待機し (既存の 503 + Retry-After ドレインを再利用)、残りのターンを中止します。実行中のプロキシは再起動の認可とドレイン調整を担当して終了し、サービス管理下ではインストール済みサービスマネージャーが置換プロセスを起動します。同じポートで、別の ID 検証済みプロセスが正常であることを確認した場合にのみ成功し、Codex インジェクションは破棄しません。これは、POST /api/stop の短いドレインよりも長く、情報に基づいたリサイクルです。
ゲートされた代替ストリームパス — 制限された単一リーダーリレー。境界のないバッファリング形状を完全に削除します。 Windows では、バンドルされた Bun リリースに #32111 修正が確実に適用されると、これが自動的にデフォルトになります。現在はオプトインのみとなっています (以下を参照)。 macOS では、そのようなリリース後でもオプトインのままになります。macOS auto を切り替えるかどうかは別の決定となります。

これらの変更による実際の RSS の改善は Windows ユーザーによる検証を待っています。リークが修正されたとは主張しません。

しきい値ベースの自動再起動は意図的に出荷されていません。プロセスがクラッシュした場合、サービスマネージャー (タスクスケジューラ/WinSW、launchd、systemd) がすでにプロセスを再起動しています。

選択肢

バンドルされたランタイム更新を待ちます。 Bun が検証可能にリリースされたら修正が適用され、opencodex はバンドルされたランタイムを強化し、より安全なストリームパスが Windows 上で自動的にオンになります (macOS では引き続き以下の明示的なオプトインが必要です)。
OPENCODEX_BUN_PATH を使用して信頼できる Bun ランタイムを実行します。 これは未検証の領域 — 私たちがテストしていないランタイムで opencodex を実行しています。自己責任で。サービスのインストールにとって重要: オーバーライドは、サービスの開始時ではなく、サービスアーティファクトの生成時に読み込まれます。環境変数を設定し、同じシェルから ocx service repair を再実行すると、パスが永続サービス定義に組み込まれます。 env を設定するだけでは、すでにインストールされているサービスには何も影響しません。
streamMode: "eager-relay" を使用して有界リレーにオプトインします。 2 つの方法: config.json を編集する ("streamMode": "eager-relay" を追加する) か、管理 API を呼び出します。PUT /api/settings と {"streamMode":"eager-relay"} は、再起動せずに新しいターンに適用されます。 クラッシュのリスク警告: Bun 1.3.14 では、#32111 の影響を受けるストリーム形状が使用されており、ストリームの途中でプロセスがクラッシュする可能性があります (Windows に限らず、どの OS でも)。サービスマネージャーはサービスを再起動しますが、実行中のリクエストは失敗します。 "legacy-tee" は現在のデフォルトを固定します。 Windows では、"auto" (デフォルト) によりランタイムゲートが決定します。 macOS では、"auto" は常に T 上にあります。明示的な "eager-relay" はオプトインです。

これらのいずれかを実際の Windows ワークロードで試した場合は、#314 の ocx doctor メモリセクションの前後を報告してください。これがまさにこの軽減策が待っている検証です。