Claude chat cannot run tests with .env.testing. environment

Laravel Package Version

1.0.18

Laravel Version

12.26.2

PHP Version

8.4.10

System Info

macOS, Latest Herd

Description

using Claude code to run tests (php artisan test), the tests were constantly running against the .env not using .env.testing.

This happens because claude uses an internal process and is not picking up the environment correctly. Also passing --env=testing etc was not working.

Workaround for me was to add this snippet below to my claude.local.md file. Maybe there is a better prompt to also add more variables from the phpunit.xml or something. But this is a heads-up for people running into the same problem.

Testing

Pest test framework
Uses SQLite for testing database

⚠️ CRITICAL: Claude Code Testing Environment Fix

Claude Code subprocess doesn't properly detect Laravel's testing environment, causing tests to use local environment instead of SQLite.

ALWAYS use this command for tests in Claude Code:

DB_CONNECTION=sqlite DB_DATABASE=:memory: CACHE_STORE=array QUEUE_CONNECTION=sync SESSION_DRIVER=array BROADCAST_CONNECTION=null php artisan test

This bypasses Laravel's environment detection and forces SQLite, preventing local database clearing during tests.

Steps To Reproduce

without above snippet. Run a php artisan test in claude chat. It will setup and tear down on the .env not using .env.testing

Also if the phoenix.xml is setup correctly. When doing 'php artisan test` from a regular terminal in the same project the tests are running again the .env.testing environment.

Upgrading to the latest version of Boost will resolve the issue, as process isolation issue was fixed in v1.1.0.

I am still having issues with this. Can anyone confirm it solved it for them. I am on boost 1.3. Confirmed that workaround works, but obviously shouldnt be needed.

I am still having issues with this. Can anyone confirm it solved it for them. I am on boost 1.3. Confirmed that workaround works, but obviously shouldnt be needed.

which workaround ?

@pushpak1300 I think the reason this happens when running php artisan test is that there's no tool to run in a subprocess, the isolation/unsetting of env vars only happens on tools, and claude usually uses its own Bash tool to run Bash(php artisan test) which inherits env still, I'm uncertain what the best approach would be here, maybe another tool? but doing a testing tool sounds like it will introduce a lot of complexity

for context if I got this correctly , this is the line with the fix you where talking about that was introduced (then changed) in v1.1.0, right?

boost/src/Mcp/ToolExecutor.php

Lines 25 to 65 in 0453d11

    
           protected function executeInSubprocess(string $toolClass, array $arguments): Response 
        
           { 
        
               $command = $this->buildCommand($toolClass, $arguments); 
        
               // We need to 'unset' env vars that will be passed from the parent process to the child process, stopping the child process from reading .env and getting updated values 
        
               $env = (Dotenv::create( 
        
                   Env::getRepository(), 
        
                   app()->environmentPath(), 
        
                   app()->environmentFile() 
        
               ))->safeLoad(); 
        
               $cleanEnv = array_fill_keys(array_keys($env), false); 
        
               $process = new Process( 
        
                   command: $command, 
        
                   env: $cleanEnv, 
        
                   timeout: $this->getTimeout($arguments) 
        
               ); 
        
               try { 
        
                   $process->mustRun(); 
        
                   $output = $process->getOutput(); 
        
                   $decoded = json_decode($output, true); 
        
                   if (json_last_error() !== JSON_ERROR_NONE) { 
        
                       return Response::error('Invalid JSON output from tool process: '.json_last_error_msg()); 
        
                   } 
        
                   return $this->reconstructResponse($decoded); 
        
               } catch (ProcessTimedOutException) { 
        
                   $process->stop(); 
        
                   return Response::error("Tool execution timed out after {$this->getTimeout($arguments)} seconds"); 
        
               } catch (ProcessFailedException) { 
        
                   $errorOutput = $process->getErrorOutput().$process->getOutput(); 
        
                   return Response::error("Process tool execution failed: {$errorOutput}"); 
        
               } 
        
           }

@Crowly34 Yep, Boost does refresh the environment when you run it. Ideally, Claude-code could do the same thing on its own. It’s actually a bug in Claude, not Boost, but I’m still mulling it over. I was also thinking about adding the artisan runner tool, but I’m not sure if that’s the right move right now.

@pushpak1300 i went down this rabbit-hole yesterday, seems like it's not even a Claude code issue, the main one is bun which cc "native" uses, by default it copies .env to have all variables, but I agree, definitely doesn't seem like a boost related issue

EDIT: leaving a somewhat related discussion on the bun repo: oven-sh/bun#1564

Leaving this in case its useful for anyone searching this issue:
One other workaround if you can't set .env.testing here is to create a custom .env.claude file and point bun to use it, you can create an alias for it if you want: alias claude='bun --env-file=.env.claude run claude and that .env file should contain all desired env state for when claude is running tools that aren't part of Laravel Boost, not ideal but maybe useful if you cannot set either .env or .env.testing as they are.

Boost is to help AI tools with Laravel development, right? If so, shouldn't this issue be reopened until its resolved? The workaround solves it in most cases, but ive had it ignore a few times since then and of course my db was wiped. Restoring a db isnt a huge deal except any test data that I setup in the app while developing a feature is now gone. Cant be running a db dump every time I run claude, etc.

Boost is to help AI tools with Laravel development, right? If so, shouldn't this issue be reopened until its resolved? The workaround solves it in most cases, but ive had it ignore a few times since then and of course my db was wiped. Restoring a db isnt a huge deal except any test data that I setup in the app while developing a feature is now gone. Cant be running a db dump every time I run claude, etc.

@MACscr I get where you're coming from but (I think) the simple answer is that this should not be open until its resolved because this is not an issue generated by laravel/boost, is not even an issue with Claude Code directly, but with bun, so there's nothing the repo can do to fix it.

Also the workaround for a user is pretty easy: just switch from using Claude Code in native to use Claude Code with npm and the npm implementation runs tests isolated perfectly fine.

Happy to help migrating to npm's Claude Code or with debugging if I can if you have some specific issues though

	protected function executeInSubprocess(string $toolClass, array $arguments): Response
	{
	$command = $this->buildCommand($toolClass, $arguments);

	// We need to 'unset' env vars that will be passed from the parent process to the child process, stopping the child process from reading .env and getting updated values
	$env = (Dotenv::create(
	Env::getRepository(),
	app()->environmentPath(),
	app()->environmentFile()
	))->safeLoad();

	$cleanEnv = array_fill_keys(array_keys($env), false);

	$process = new Process(
	command: $command,
	env: $cleanEnv,
	timeout: $this->getTimeout($arguments)
	);

	try {
	$process->mustRun();

	$output = $process->getOutput();
	$decoded = json_decode($output, true);

	if (json_last_error() !== JSON_ERROR_NONE) {
	return Response::error('Invalid JSON output from tool process: '.json_last_error_msg());
	}

	return $this->reconstructResponse($decoded);
	} catch (ProcessTimedOutException) {
	$process->stop();

	return Response::error("Tool execution timed out after {$this->getTimeout($arguments)} seconds");

	} catch (ProcessFailedException) {
	$errorOutput = $process->getErrorOutput().$process->getOutput();

	return Response::error("Process tool execution failed: {$errorOutput}");
	}
	}