Forkserver-backed IPython kernel can terminate on Python 3.14

[teobucos]

Description

On Linux with a Python 3.14 kernel, a forkserver-backed IPython kernel terminated twice in the same long-lived resumed Prime Agent session while a cell was waiting for a subprocess-driven, multi-step local verification command.

The Prime daemon and session worker remained alive. Every later IPython call in that session returned Kernel has been shut down, and the kernel did not restart automatically.

This appears intermittent or dependent on long-lived/resumed session state: short clean sessions using the forkserver completed a 35-second subprocess and the same verification workload successfully.

Steps observed

1. Configure PRIME_AGENT_KERNEL_PYTHON to a Python 3.14.7 environment containing ipykernel and the Prime runtime.
2. Start a persistent session with the default Linux forkserver enabled.
3. Resume or clone a long-lived session.
4. From IPython, wait for a subprocess-based local verification workload:

result = subprocess.run(
    ["make", "doctor"],
    text=True,
    capture_output=True,
    timeout=300,
)

5. During two separate attempts, the kernel terminated while the command was running. Later IPython calls immediately failed.

The command name above represents a local multi-step verification target; its individual subprocesses all complete successfully when run outside Prime.

Expected behavior

The subprocess completes and the persistent kernel remains available for later IPython calls. If a kernel does exit, a later call should provision a replacement instead of permanently returning the shutdown error.

Actual behavior

The session reported:

Kernel has been shut down

Process inspection confirmed the affected kernel used Prime's forkserver path. There was ample available memory and no OOM or system-level kill entry. The exact signal or lower-level cause was not captured.

Environment

• Prime Agent: 0.8.1
• OS: Linux 6.8 x86_64
• Node.js: 22.23.2
• Kernel Python: 3.14.7
• ipykernel: 7.3.0

Isolation and workaround

After restarting the session with:

export PRIME_AGENT_KERNEL_FORKSERVER=0

the same verification workload completed successfully, a second IPython call returned normally, and the direct-spawn kernel remained alive while additional kernels were created.

This strongly isolates the failure to the forkserver-backed path, but does not establish the precise implementation defect. A fresh short-lived forkserver session did not reproduce it, so long-lived/resumed state or concurrency may be relevant.

[alexanderkjeldaas]

This happens every 5 minutes for me.

[snimu]

Addressed by #1685