›_ Codex Issues
Codex Issues / #18995

Windows: stdio MCP handshake fails with Laravel Boost (php artisan boost:mcp) in Codex CLI 0.122.0

Open 💬 2 comments Opened Apr 22, 2026 by hypeneural
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Upstream Issue Draft

Suggested title

Windows: stdio MCP handshake fails with Laravel Boost (php artisan boost:mcp) in Codex CLI 0.122.0

Suggested labels

  • bug
  • windows
  • mcp

How to open after GitHub auth

The npm package points to:

  • repository: https://github.com/openai/codex
  • issues: https://github.com/openai/codex/issues

After authenticating gh, open the issue with:

gh issue create --repo openai/codex --title "Windows: stdio MCP handshake fails with Laravel Boost (php artisan boost:mcp) in Codex CLI 0.122.0" --body-file docs/active/laravel-boost-codex/UPSTREAM-ISSUE.md

Summary

On Windows, Codex detects the Laravel Boost MCP server configuration and scopes it correctly to the Laravel app, but the MCP client fails during the initial handshake.

The same Boost server responds correctly outside Codex when spoken to over stdio with newline-delimited JSON-RPC, which suggests the failure is in the Codex client path on this Windows environment rather than in the Boost server itself.

Environment

  • OS: Windows
  • Shell: PowerShell
  • Codex CLI:
  • 0.122.0-alpha.13 via VS Code extension openai.chatgpt
  • 0.122.0 via npm i -g @openai/codex@latest
  • Laravel app:
  • Laravel 13.3.0
  • PHP 8.3
  • laravel/boost v2.4.4
  • MCP config:
[mcp_servers.laravel-boost]
command = "php"
args = ["artisan", "boost:mcp"]
cwd = "."
required = false
startup_timeout_sec = 20

Reproduction

  1. Open Codex in the Laravel app directory:
codex --cd apps/api
  1. Let startup finish, then run:
/mcp
  1. Reproduce the same condition in non-interactive mode:
codex exec -C apps/api -s read-only -c mcp_servers.laravel-boost.required=true --color never "Use the laravel-boost MCP server if available and list one tool name it exposes. Do not change files."

Expected behavior

  • Codex starts the laravel-boost MCP server successfully.
  • /mcp lists laravel-boost as active.
  • A Boost tool such as application-info or search-docs can be called successfully inside Codex.

Actual behavior

  • Interactive TUI startup shows:
MCP client for `laravel-boost` failed to start: MCP startup failed: handshaking with MCP server failed: connection closed: initialize response
MCP startup incomplete (failed: laravel-boost)
  • /mcp lists only:
  • codex_apps
  • openaiDeveloperDocs
  • codex exec with required = true fails with:
required MCP servers failed to initialize: laravel-boost: handshaking with MCP server failed: connection closed: initialize response

Counterproof: Boost server itself is healthy

Running the server directly outside Codex works:

  • initialize returns successfully
  • tools/list returns tools
  • confirmed tools include:
  • application-info
  • browser-logs
  • database-connections
  • database-query
  • database-schema
  • get-absolute-url
  • last-error
  • read-log-entries
  • direct calls to application-info and search-docs succeed

Additional experiments already tried

These did not change the result:

  • startup_timeout_sec = 60
  • absolute php.exe path instead of php
  • switching Codex from the VS Code extension binary to global npm @openai/codex@0.122.0
  • codex exec --enable unified_exec

Why this looks client-side

  • Codex scopes the MCP config correctly:
  • codex mcp list in repo root does not show laravel-boost
  • codex mcp list in apps/api does show laravel-boost
  • The Boost server responds correctly over stdio outside Codex
  • The same failure reproduces in both:
  • interactive TUI
  • codex exec
  • The same failure reproduces on both:
  • 0.122.0-alpha.13
  • 0.122.0

Local operational decision

For now the MCP remains configured with:

  • required = false

We are treating installation/publication as complete, but not promoting the MCP to required startup until a Codex version newer than 0.122.0 succeeds on Windows.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #18486
  • #18977

Powered by Codex Action

hypeneural · 4 months ago

Follow-up after reviewing #18486, #18977, and #16899: local workaround confirmed for Laravel Boost on Windows.

The failure still reproduces with the original stdio config, so I do not think this issue should be closed as fixed. However, the Streamable HTTP workaround described in #16899 also works for Laravel Boost because laravel/mcp can register the same Boost server as a web MCP route.

Local Laravel change:

// routes/ai.php
use Laravel\Boost\Mcp\Boost;
use Laravel\Mcp\Facades\Mcp;

if ((bool) config('boost.enabled', true) && app()->environment(['local', 'development'])) {
    Mcp::web('/_boost/mcp', Boost::class);
}

Codex project config:

[mcp_servers.laravel-boost]
url = 'http://127.0.0.1:8000/_boost/mcp'
required = false
startup_timeout_sec = 20
tool_timeout_sec = 120

Validation on Windows with codex-cli 0.122.0:

  • direct HTTP initialize => HTTP 200, MCP-Session-Id present, serverInfo Laravel Boost
  • direct HTTP notifications/initialized => HTTP 202
  • direct HTTP tools/list => HTTP 200, 9 Boost tools returned
  • codex exec -C apps/api -s read-only -c mcp_servers.laravel-boost.required=true ... succeeded and called a real Boost tool: laravel-boost/database-connections

So the actionable workaround for this Laravel Boost case is: avoid stdio on Windows and point Codex at a local Streamable HTTP MCP endpoint. The underlying stdio startup/handshake bug remains, because the original php artisan boost:mcp config still fails before this workaround.