Thanks for submitting a PR!

Note that draft PR's are not reviewed. If you would like a review, please mark your pull request as ready for review in the GitHub user interface.

Pull requests that are abandoned in draft may be closed due to inactivity.

Thanks for this, it realy does keep crashing for me on windows with timeout messages.

Thanks for this, it realy does keep crashing for me on windows with timeout messages.

After applying this PR, turn on process isolation in boost.php, ever since I did that, no more crashes from the timeout issue on Windows in VSCode. (if you had the boost.php config published before this change, remove it or add manually new options)

More recently, I also set isolation to be enabled by default, even if your old config didn’t include that option. 75d215f

Since parts of this PR were already implemented in feat: default process isolation to true, things are much simpler now. With the config section removed as requested and the fallback changed from false to true, the code relies on config('boost.process_isolation.enabled', true) which always returns true.

Windows users get safe process isolation by default, and this PR now simply focuses on platform-aware timeout handling and test coverage.

Since parts of this PR were already implemented in feat: default process isolation to true, things are much simpler now. With the config section removed as requested and the fallback changed from false to true, the code relies on config('boost.process_isolation.enabled', true) which always returns true.

Windows users get safe process isolation by default, and this PR now simply focuses on platform-aware timeout handling and test coverage.

🤔 What do you think about us removing the process isolation configuration entirely, so we can always rely on the subprocess timeout management?

Then in ToolExecutor use $arguments['timeout'] ?? 180 as the timeout?

Thinking
Originally the config was there in case the process isolation had issues, but it's been working really well for me and I don't see why it should ever be disabled.

Right now, as you documented, if somebody disables process isolation, then we use set_time_limit in Tinker and their code takes too long, the entire MCP process dies.

Two options
Fundamentally the Tinker tool should always run the eval'ed code in a fork or subprocess to protected against that, so we could add that into the Tinker tool additionally, or just only work with process isolation because it's great and works?

I recognise this is a departure from your original plan, but it solves the same issue and simplifies the Tinker tool a lot.

@ashleyhindle you're right - that was actually my first instinct too, but I second-guessed myself thinking the changes might be too brutal for the initial PR. The current approach of always using subprocess with getTimeout() method that extracts $arguments['timeout'] ?? 180 and clamps it between 1-600 seconds eliminates the crash risk completely while dramatically simplifying the architecture.

One thing I'd also suggest is reconsidering the hardcoded ini_set('memory_limit', '128M') in Tinker - for large projects this might be too restrictive. It should probably be configurable or at least doubled to 256M to ensure it works properly across different project sizes without running into memory issues during code execution.