Boost doesn't detect environment changes

[poisa]

Laravel Package Version

1.0.17

Laravel Version

12.24.0

PHP Version

8.4.11

System Info

macOs 15.6 with Herd 1.22.0, Cursor 1.4.5

Description

I installed Boost with a vanilla Laravel install using the sqlite driver. I changed to the mysql driver but the MCP server in Cursor continued returning sqlite as the default database driver both when ran using the get-config tool and when running return config("database.default"); via Tinker.

The solution was to restart Cursor. Seems that either Boost or Cursor are caching the results from the MCP calls. I'm reporting it here in case this is a Boost configuration.

Steps To Reproduce

1. Install a vanilla Laravel app
2. Install Boost
3. Change laravel to use a mysql connection
4. Ask the Cursor Agent to find out which is the default database connection (or ask it to create a new table).

It will attempt to use the sqlite connection in its generated commands or will try to verify that it's work is complete by querying the wrong database driver.

[thejamescollins]

I had a similar issue, where tinker commands via boost didn't seem to detect the latest code changes I had made.

Is it possible that boost has a long running tinker process that it reuses m, instead of starting a new one each time the chat tries to run a tinker command?

If so, I think a new process each time would be the safest way to operate.

[xHeaven]

I had a similar issue, where tinker commands via boost didn't seem to detect the latest code changes I had made.

Is it possible that boost has a long running tinker process that it reuses m, instead of starting a new one each time the chat tries to run a tinker command?

If so, I think a new process each time would be the safest way to operate.

Laravel Boost itself is the long running process. There is no separate Tinker process, Boost just evals the code the LLM sends to it internally and then returns whatever.

Configurations are also bootstrapped at the time of the first run, and there is practically no way to do anything with this, unless you want to re-bootstrap the entire thing every time you ask for configuration values (or wherever any kind of configuration value is used).

If you want to mess with the .env, restart the MCP server after modifying it.

[Plytas]

So perhaps there could be a artisan boost:restart command that would send a signal to the mcp server? Similar to how horizon works.

[alexkart]

I had a similar issue, where tinker commands via boost didn't seem to detect the latest code changes I had made.

Is it possible that boost has a long running tinker process that it reuses m, instead of starting a new one each time the chat tries to run a tinker command?

If so, I think a new process each time would be the safest way to operate.

I just had the same issue. Claude Code modified the model and ran Tinker tool to test the change, but the update wasn’t visible. Claude Code tried everything (wasted quite a bit of tokens) until finally restarting PHP on the server, and only then did Tinker reflect the change. This basically makes Tinker MCP unusable, since it doesn’t recognize the changes Claude Code makes. I think it's a critical issue.

[xHeaven]

So perhaps there could be a artisan boost:restart command that would send a signal to the mcp server? Similar to how horizon works.

It's not that simple. The MCP client also needs to be notified (in this case it's either Cursor or Claude Code, or whatever) about that change, otherwise it won't reconnect to the server. I don't think this is possible right now.

Horizon works, because nothing depends on that specific instance staying up. In this case, the specific MCP server instance is linked to the MCP client - restarting the MCP server inevitably means that the MCP client loses connection to the server and won't be able to reconnect to it, because it's that MCP client that has to start the server itself.