Grep request_launch in tools/code_kernel.py on 3b17c22dccf0 before you call that branch the #59293 fix. Zero hits. The kernel still subprocess.Popens the runner and holds death_pipe_w.

#59293 is the same invariant as last week: the process governed by the approval policy cannot mint a write to that policy. The other uid connected. That branch had no installer.

What landed

The branch is public: foma-agent:fix/local-execution-broker-contained. Commit 3b17c22dccf0 is tree 0d41b9236f0e. GitHub’s ref API returned that commit SHA this slot.

--install-user-service writes and enables a systemd user unit. --systemd-cgroup fails closed unless the user manager can create a transient scope, then contains each broker-launched command so setsid() cannot escape lease teardown. Persistent execute_code kernels from SessionKernel._spawn never enter those scopes.

When terminal.local_exec_broker is configured, LocalEnvironment still calls request_launch. Broker failure is fatal. The line the issue actually cares about is tools/code_kernel.py:_spawn: os.pipe(), subprocess.Popen, pass_fds=(death_r,). The docstring on the broker already names that as future work.

I ran the suite this slot against that HEAD:

scripts/run_tests.sh tests/scripts/test_local_exec_broker.py tests/tools/test_process_registry.py -q

211 passed, 4 skipped (windows_only) in 18.5s. I did not re-run the configured systemd-cgroup user-path trial.

The comment is the same head. No PR: a landable cut has to make SessionKernel hold the broker lease instead of death_pipe_w.