if laravel-boost appears in a comment inside mcpServers, install does nothing and still reports ✓.
.mcp.json:
{
"mcpServers": {
// "laravel-boost": { "command": "php", "args": ["artisan","boost:mcp"] }
}
}php artisan boost:install --mcp prints Claude Code.. ✓ and exits 0. file comes back byte identical, nothing registered.
cause: FileWriter::serverExistsInContent() (src/Install/Mcp/FileWriter.php:176) regexes the raw slice between the mcpServers braces, comments included. so filterExistingServers() comes back empty and injectIntoExistingConfigKey() hits the return true at :126.
what does and doesn't trigger it, inside mcpServers:
| comment |
installed |
// "laravel-boost": {...} |
no |
// laravel-boost: disabled |
no |
// re-enable laravel-boost later |
yes |
json5 path only. plain json goes through json_decode and is fine, and codex/toml is fine too since that check anchors ^\[. it isn't specific to boost's own key either, I got the same result driving FileWriter directly with a nightwatch key.
commenting a server out and later running install to bring it back seems normal enough, that's where it bit me.
if anyone picks this up, one thing to watch: stripping // before the check would also eat // inside string values like "url": "https://x", which flips it into a duplicate insert instead. needs to be string aware.
happy to PR it, just wasn't sure which way you'd want the check done.
if
laravel-boostappears in a comment insidemcpServers, install does nothing and still reports ✓..mcp.json:{ "mcpServers": { // "laravel-boost": { "command": "php", "args": ["artisan","boost:mcp"] } } }php artisan boost:install --mcpprintsClaude Code.. ✓and exits 0. file comes back byte identical, nothing registered.cause:
FileWriter::serverExistsInContent()(src/Install/Mcp/FileWriter.php:176) regexes the raw slice between themcpServersbraces, comments included. sofilterExistingServers()comes back empty andinjectIntoExistingConfigKey()hits thereturn trueat:126.what does and doesn't trigger it, inside
mcpServers:// "laravel-boost": {...}// laravel-boost: disabled// re-enable laravel-boost laterjson5 path only. plain json goes through
json_decodeand is fine, and codex/toml is fine too since that check anchors^\[. it isn't specific to boost's own key either, I got the same result drivingFileWriterdirectly with anightwatchkey.commenting a server out and later running install to bring it back seems normal enough, that's where it bit me.
if anyone picks this up, one thing to watch: stripping
//before the check would also eat//inside string values like"url": "https://x", which flips it into a duplicate insert instead. needs to be string aware.happy to PR it, just wasn't sure which way you'd want the check done.