@rebeccahum Thanks for introducing a PR!

I'm not yet sure what specific problem this is meant to solve. For individual call, you can already provide a custom array of values to adapt the behavior.

Adding a filter like this would only make sense if you want to modify the behavior of all calls, or calls outside of your direct control.

I think this would likely introduce many bugs, as some calls might rely on the fact that the defaults are not filterable yet and would only override the values that need changing. If other values changed as well in this unexpected way, it might cause these calls to break.

Can you tell me a bit more about the use case you had in mind?

@schlessera Thanks for taking a look. The specific use case for this would be to set the launch parameter to false by default, as we're seeing that WP_CLI::runcommand() does not work when using php-fpm for handling cron events, as it shells out to php for running a wp command (and now that we are in a chrooted fpm environment, there are no binaries for it to shell out to). Since the launch parameter is set to true by default and rather than having one pass it in manually each time, we want to default to false (especially for those unaware of the use case requiring that).

Which particular error condition is being triggered in that case?

I think it might be safer to add an opt-in mechanism instead to have a launch=true command that fails on preparing the environment to retry again as a launch=false command.

This would not change any existing behavior unless it was already broken in the first place.

I'm thinking about setting an environment variable that lets you opt in to this mechanism, like WP_CLI_LAUNCH_INLINE_FOR_FAILED_PROCESS_CREATION or something like that.

Do you think that would solve your use case?

@schlessera When WP_CLI::runcommand does proc_open(/usr/local/bin/php-fpm) that binary is not found (since there are really no binaries in the chroot environment), we get back a 127 error code. Based on that error, would that opt-in mechanism you've briefly described work for that use case?

Proceeding with #5594 for this repository. I've captured this PR to https://gist.github.com/danielbachhuber/b45248df9e02eddb297935b0c6157eb1 in case this PR is auto-closed or broken in some way.