Running VSCode with both OpenClaw (Claude-in-VSCode) and the official Jupyter extension. Every time I trigger OpenClaw on a `.ipynb` file, the Jupyter kernel dies. Have to restart kernel constantly.
My environment:
* VSCode: 1.91.0
* OS: Windows 11 23H2
* Extensions:
* ms-toolsai.jupyter (v2024.10.0)
* OpenClaw.claude-in-vscode (v0.2.1)
* GitHub.copilot (v1.180.0)
Tried:
* Disabling Copilot → no change.
* Setting OpenClaw to not auto-start → kernel still dies when I invoke it manually.
* Using a fresh Python environment → same issue.
Error in Jupyter Output:
```
Kernel died with exit code 4294967295.
```
Anyone replicated this? Need to know if it's my setup or a known conflict.
- bench_beast
Benchmarks don't lie.
That exit code 4294967295 is a classic Windows kernel death signal, essentially a -1 in unsigned 32-bit. It's usually a catastrophic resource clash or memory issue.
Those two extensions are likely fighting over the same IPC channels or Python interpreter. The Jupyter extension spawns a kernel process, and OpenClaw probably tries to hook into it for context, stepping on its toes. Seen similar with older versions of Copilot Labs and IPython.
Quick workaround? Try setting your Jupyter kernel to run in a separate, isolated environment.
1. Open the Jupyter notebook.
2. Click the kernel picker in the top right (might say "Python 3.x").
3. Select "Select Another Kernel..."
4. Pick "Python Environments" and choose a *different* interpreter than your default VSCode one.
Forces a clean separation. If it works, you've confirmed it's a process sandboxing bug. File it with OpenClaw and tag the Jupyter team.
- elle
Good catch on the exit code translation. That's spot on for a process collision on Windows.
Your workaround is valid, but I'd add that the kernel isolation often fails if both extensions are pulling from the same `site-packages` directory, even with different interpreter paths. A more nuclear option is to run the Jupyter kernel in a full container using the "Dev Containers" extension. It's overkill, but it guarantees the IPC channels are namespaced away from OpenClaw's reach.
Also, check if OpenClaw has any config for its Python worker path. Some of these AI coding assistants spawn a hidden Python subprocess, and if it's pointed at the same binary the Jupyter kernel uses, they'll deadlock on the GIL or a mutex.