0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@spumoni(spumoni)

【Windows】Codex CLIでapp-server daemonが0.157.0から更新されないバグの回避方法 : ターミナルが出まくる問題

0
Last updated at Posted at 2026-10-05

Codex CLIを最新版（v0.160.0など）にアップデートしたにもかかわらず、バックグラウンドで動く app-server daemon のバージョンだけが v0.157.0のまま固定されてしまう現象への対処方法の備忘録です。

この記事では、daemon を新しいバージョンに更新し、ピン留めを解除して標準の自動更新を行う設定に戻すところまでを扱います。2026年10月8日の環境では、CLI と daemon のバージョン不一致を解消し、標準の更新コマンドが成功する状態まで復旧しました。

一方、最初の更新失敗の原因は未特定であり、ターミナルウィンドウが次々に開く現象の解消も確認できていません。daemon 更新の復旧と、これらの問題の原因究明・修正は分けて説明します。

現象と原因

CLI 本体と daemon は別々のパッケージとして管理されています。そのため、CLI 本体を更新しても、バックグラウンドでは古い daemon が動作していることがあります。

今回確認した環境では、--from-cli --yes で daemon をピン留めした後、CLI 本体だけが更新されていました。ピン留め中の daemon は標準の自動更新の対象から外れるため、CLI が 0.161.0 になっても daemon は 0.160.1 のままでした。

また、タスク実行時に大量のターミナルウィンドウ（cmd/pwsh）が次々にポップアップしては閉じる現象も報告していました。ただし、バージョン不一致との因果関係や、今回の更新による解消は確認できていません。

標準の更新を試みた際には、以下のエラーも発生しました。

> codex app-server daemon update
Error: standalone Codex updater exited with status exit code: 1

まず現象を確認する

作業の前に、CLI本体とデーモンのバージョンがずれているかを確認します。PowerShellで以下を実行してください。

CLI本体のバージョン：

codex --version

デーモンのバージョン：

codex app-server daemon version

判定の目安

  • cliVersion と appServerVersion が異なる → CLI と稼働中の daemon にバージョン差があります。過去に --from-cli --yes を実行した場合は、ピン留めが残っていないか確認します。
  • バージョンが一致している → 現時点のバージョン差はありません。ただし、ピン留めの解除まで確認できたことにはなりません。ピン留めしている場合は、手順 5 の標準更新に戻す操作が必要です。

標準の自動更新は CLI の更新とは別のタイミングで確認するため、一時的なバージョン差だけで更新失敗とは判断できません。

確認結果は、手順の完了後に比較できるようメモしておくと便利です。

解決手順：CLIパッケージから強制同期（ピン留め）する

標準の更新に失敗するときは、CLI本体のパッケージ（例：v0.160.0）をデーモン側にコピーし、一時的にバージョンを同期する方法があります。

ただし、この操作は daemon のバージョンをピン留めします。同期を確認した後、手順 5 でピン留めを解除し、手順 6 で標準の更新に戻ったことを確認するところまで進めてください。

PowerShell（管理者権限は不要）を開き、以下のコマンドを順番に実行します。

1. 古いプロセスの強制終了

まず、バックグラウンドで動いている古いCodexのプロセスを確実に終了させます。実行中のCodexセッションもすべて終了するため、作業中の内容は先に保存してください。

taskkill /f /im codex.exe

2. デーモンの一時ファイルの削除

古いデーモンが「まだ起動している」と誤認する原因となるファイルを削除します。

Remove-Item -Path "$env:USERPROFILE\.codex\app-server-daemon\*" -Recurse -Force -ErrorAction SilentlyContinue

3. CLIからの強制アップデート（ピン留め）

通常の update ではなく --from-cli フラグを付けて、その時点の CLI パッケージを daemon 用にコピーし、ピン留めします。

codex app-server daemon update --from-cli --yes

【成功時のログ出力例】
以下のように installedVersion が最新（v0.160.0など）に切り替わっていれば成功です。

Replace installed daemon version 0.157.0 with CLI version 0.160.0 from ...
The selected package will be pinned.
{"status":"updated","installedVersion":"0.160.0","runningVersion":null,...}

4. デーモンの起動と同期の確認

コピーしたパッケージでデーモンをバックグラウンドで起動します。

codex app-server daemon start

最初に確認したときと同じコマンドで、バージョンを再確認します。

codex app-server daemon version

managedCodexVersion と appServerVersion が、コピー元の CLI と同じバージョン（v0.160.0など）になっていれば、インストール済みのパッケージと稼働中の daemon の同期を確認できます。runningVersion は、更新コマンドなどの結果に含まれる項目です。

この時点では、まだピン留めされた状態です。続けて標準の自動更新に戻します。

5. ピン留めを解除して標準の自動更新へ戻す

--from-cli --yes によるピン留めを残すと、その後に npm で CLI を更新しても、固定された daemon は新しいバージョンへ自動更新されません。

次の標準コマンドでピン留めを解除し、通常の自動更新に戻します。daemon の再起動を伴うため、実行中の作業を終了してから PowerShell で実行してください。

5-1. 標準の更新コマンドを実行する

codex app-server daemon update

このコマンドが正常に完了すると、通常のリリースを選択した状態に戻ります。自動更新が別途無効に設定されていなければ、標準の自動更新の対象になりますが、以下のようなエラーが発生した場合、さらに処理が必要です。

Error: standalone Codex updater exited with status exit code: 1

5-2. 失敗した場合は公式インストーラーを直接実行する

公式インストーラーを直接実行して、ピン留めされたパッケージから通常の最新リリースへ切り替え、自動更新用の auto-update-version マーカーを作成します。

# Codex の保存場所を取得する。
# CODEX_HOME が未指定なら、既定のユーザーフォルダー内の .codex を使う。
$codexHomePath = if ([string]::IsNullOrWhiteSpace($env:CODEX_HOME)) {
    Join-Path $env:USERPROFILE '.codex'
} else {
    $env:CODEX_HOME
}

# 現在使用する daemon パッケージを指すジャンクションのパスを組み立てる。
$daemonCurrentPath = Join-Path $codexHomePath 'packages\app-server-daemon\current'

# ジャンクションの参照先から、現在選択されているパッケージの名前を取得する。
# 後の復旧操作で、対象が途中で変わっていないことを確認するために使う。
$selectedRelease = Split-Path -Leaf (Get-Item -LiteralPath $daemonCurrentPath -ErrorAction Stop).Target

# 公式インストーラーを保存する、一時フォルダー内のファイル名を決める。
$codexInstallerPath = Join-Path $env:TEMP 'codex-official-install.ps1'

# 公式インストーラーをダウンロードする。ファイルの実行は次のコードで行う。
Invoke-WebRequest -Uri 'https://chatgpt.com/codex/install.ps1' `
    -OutFile $codexInstallerPath -ErrorAction Stop

次に、公式インストーラーが使う環境変数を一時的に設定して実行します。

  • CODEX_INSTALL_DAEMON_ONLY=1：daemon 用パッケージだけを更新します。
  • CODEX_INSTALL_IF_CURRENT=1 と CODEX_UPDATE_FROM_RELEASE：操作中に別のパッケージへ切り替わっていないことを確認し、現在のピン留めから通常のリリースへ戻します。
  • CODEX_RELEASE=latest：通常の最新リリースを選択し、自動更新用マーカーも作成します。

以下では、環境変数の元の値を保存し、インストーラーの実行後に戻しています。

$codexInstallEnv = @{
    CODEX_INSTALL_DAEMON_ONLY = '1'
    CODEX_RELEASE = 'latest'
    CODEX_NON_INTERACTIVE = '1'
    CODEX_INSTALL_IF_LATEST = '0'
    CODEX_INSTALL_IF_CURRENT = '1'
    CODEX_UPDATE_FROM_RELEASE = $selectedRelease
    CODEX_INSTALL_DEFER_SELECTION = '0'
}

$previousCodexInstallEnv = @{}
foreach ($name in $codexInstallEnv.Keys) {
    $previousCodexInstallEnv[$name] = [Environment]::GetEnvironmentVariable($name, 'Process')
}

try {
    foreach ($name in $codexInstallEnv.Keys) {
        [Environment]::SetEnvironmentVariable($name, $codexInstallEnv[$name], 'Process')
    }

    & "$env:SystemRoot\System32\WindowsPowerShell\v1.0\powershell.exe" `
        -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Bypass `
        -File $codexInstallerPath

    if ($LASTEXITCODE -ne 0) {
        throw "公式インストーラーが終了コード $LASTEXITCODE で失敗しました。"
    }
} finally {
    foreach ($name in $previousCodexInstallEnv.Keys) {
        [Environment]::SetEnvironmentVariable($name, $previousCodexInstallEnv[$name], 'Process')
    }
}

今回の環境では、この操作で current の参照先が releases/local-… から releases/0.161.0-x86_64-pc-windows-msvc に切り替わり、auto-update-version に 0.161.0-x86_64-pc-windows-msvc が記録されました。これによりピン留めは解除されました。

この段階では、インストール済みのパッケージが新しくなっていても、稼働中の daemon は古いバージョンのままでした。続けて標準コマンドで更新処理と再起動を行います。

5-3. 標準の更新コマンドを再実行する

codex app-server daemon update

今回の環境では、再実行した標準コマンドのインストール処理が成功し、60 秒の終了待ちの後に daemon の再起動も完了しました。手順 6 で、インストール済みと稼働中のバージョン、および自動更新の設定を確認します。

この結果、今回の環境では標準の更新コマンドを使える状態に復旧しました。ただし、最初の終了コード 1 の原因は未特定です。更新処理の復旧は確認できましたが、原因となった不具合を特定・修正したわけではありません。

6. 更新後のバージョンと自動更新の設定を確認する

更新後は、次のコマンドで確認します。

codex app-server daemon version

2026年10月8日の復旧後は、主な項目が次の状態になりました。実際の出力には、実行ファイルやソケットのパスなどの項目も含まれます。

{
  "status": "running",
  "managedCodexVersion": "0.161.0",
  "cliVersion": "0.161.0",
  "appServerVersion": "0.161.0"
}
項目 意味
cliVersion コマンドを実行した CLI のバージョン
managedCodexVersion インストール済みの daemon パッケージのバージョン
appServerVersion 実際に動いている daemon のバージョン

インストール済みのバージョンだけが新しくなっている場合は、再起動が完了しているかも確認してください。今回の更新ログでは、60 秒の終了待ちの後に古い daemon が終了し、新しい daemon の起動と準備完了が確認できました。

続けて、標準の自動更新に必要な auto-update-version マーカーを確認します。以下は、既定の CODEX_HOME（$env:USERPROFILE\.codex）を使う環境の例です。

Get-Content -LiteralPath "$env:USERPROFILE\.codex\packages\app-server-daemon\auto-update-version"

今回の環境では、通常のリリースを選択する次の値が記録されていました。

0.161.0-x86_64-pc-windows-msvc

更新用プロセスの稼働も確認します。

Get-CimInstance Win32_Process |
    Where-Object { $_.Name -eq 'codex.exe' -and $_.CommandLine -like '*app-server daemon pid-update-loop*' } |
    Select-Object ProcessId, CommandLine

通常のリリースを選択するマーカーと標準の更新用プロセスの稼働を確認し、ピン留めを解除して、標準の自動更新を行う設定に戻す作業は完了です。

まとめ

標準の更新に失敗した際の回避方法として、--from-cli --yes による一時的な同期があります。ただし、そのままでは daemon のバージョンが固定されるため、同期後は codex app-server daemon update で標準の自動更新に戻し、インストール済みと稼働中のバージョンを確認してください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?