What is even stranger is that theoretically, php should not be able to exit with a status code of -1 - If you try, it changes it to 255

$ php -r 'exit(-1);'
$ echo $?
255

So - How did this command php -d variables_order=E -r 'echo json_encode($_ENV);' exit with a status code of -1?

This is probs related : https://stackoverflow.com/questions/71354900/php-proc-get-status-exitcode-is-always-1-after-pcntl-fork

And here are some related release notes - https://github.com/php/php-src/blob/master/UPGRADING (These are for PHP 8.3)

Executing proc_get_status() multiple times will now always return the right
value on posix systems. Previously, only the first call of the function
returned the right value. Executing proc_close() after proc_get_status() will
now also return the right exit code. Previously this would return -1.
Internally, this works by caching the result on posix systems. If you want
the old behaviour, you can check the "cached" key in the array returned by
proc_get_status() to check whether the result was cached.

In T15586#12570, @Ekubischta wrote:

This is probs related : https://stackoverflow.com/questions/71354900/php-proc-get-status-exitcode-is-always-1-after-pcntl-fork

Yes it is! Adding 'pcntl_signal(SIGCHLD, SIG_IGN);' to the top of my test script results in an exitcode of -1 being returned. However, it does so on both of my systems. However, if I set SIGCHLD to a signal handler function like FutureIterator.php then I can replicate my fault such that the one system returns an exitcode of -1, and the other system returns 0.

#!/usr/bin/env php
<?php

function handleSIGCHLD($signo) {
}

pcntl_signal(SIGCHLD, 'handleSIGCHLD');

$proc = proc_open("/usr/bin/sleep 1", [['pipe', 'r'], ['pipe', 'w'], ['pipe', 'w']], $pipes);
do {
    $status = proc_get_status($proc);
    if (! $status['running'])
        break;
    usleep(300000);
} while (true);
echo "Exitcode: $status[exitcode]", PHP_EOL;

Raised PHP bug https://github.com/php/php-src/issues/11871

Three days ago I ran into the same output (though different steps in Phorge that I don't perfectly remember) after upgrading from PHP 8.2.8 to PHP 8.2.9 on Fedora 38. Thus I downgraded again.

The issue is in a change which went in with PHP 8.1.22, and is being reverted in PHP 8.1.23.
@aklapper - as PHP 8.2.9 isn't released yet, I assume you compiled from source? If you 'git pull' and recompile, the latest 8.2.9-dev should work. The fix was committed Aug 2 21:08:52.

For the records, I did not compile from source, I had used the official Fedora package php-8.2.9-1.fc38 created on Aug 1st from https://koji.fedoraproject.org/koji/packageinfo?packageID=72