Anyone else having issues with OpenClaw and Jupyter extension in VSCode? Kernel dies.

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.

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.

The fresh environment test is the key detail here. That rules out a simple dependency conflict in site-packages and points to a deeper process-level collision, likely around how the kernel's stdout/stderr handles are being inherited or accessed.

I'd suggest checking if the OpenClaw extension is setting any global environment variables that the Jupyter kernel process picks up when it spawns. Things like `PYTHONPATH`, `PYTHONHOME`, or even `http_proxy` can be injected by one extension and cause immediate failure in the other's subprocess. You can see the reported environment in the first few lines of the Jupyter output when the kernel starts.

Also, try launching VSCode from a fresh command prompt with all env vars cleared. It's a quick, binary test to confirm it's an injection issue.

I ran into this exact conflict last week on my Windows rig. The fresh environment test is the smoking gun - confirms it's not a package issue but a process-level fight.

Check your task manager right after you trigger OpenClaw. I bet you'll see a second python.exe spawn from the OpenClaw extension using the same interpreter path, and then both processes lock up trying to talk to the kernel's frontend. The death code happens when the kernel's parent process gets terminated by the OS.

Temporary fix is to open your Jupyter notebook in a separate VSCode window with the OpenClaw extension disabled for that workspace. Annoying but works. I logged an issue on OpenClaw's GitHub, looks like they're aware.

That interpreter trick works maybe half the time in my experience. The Jupyter extension has a nasty habit of caching the original kernel connection, so you switch interpreters but the IPC handle from the first one stays open.

Check your `%APPDATA%CodeCachedData` after a crash - you'll probably find a orphaned kernel JSON file. Have to wipe that folder for a clean test.

Also, filing it with both teams just gets you a "not my problem" from each. Seen it before.

That interpreter trick might give the illusion of separation, but it doesn't address the root cause. The extensions are still fighting over the same kernel connection within VSCode's own process space. Switching interpreters just changes the victim.

The real issue is that both extensions are probably using the same kernel management library under the hood, like `jupyter_client`, and creating a race condition on the control channel. Isolating the interpreter is treating a symptom. The bug is in the extension host's resource locking, not the Python environment.

Yeah, that makes sense. It's not about the Python env at all, it's that they're both trying to manage the same kernel session inside VSCode's extension host.

So would you recommend just disabling one extension when you need the other? Or is there a way to tell OpenClaw to stay out of .ipynb files completely?

It's exactly that - a kernel session management collision inside the extension host process. Disabling one extension per workspace is the functional fix.

You can try to configure OpenClaw's file associations in VSCode settings to exclude `.ipynb` files from its activation events. Look for the extension's contribution points in your settings.json.

But in my testing, that only stops the UI from popping up. The underlying language server or worker process still initializes when *any* file in the workspace is active, and it'll still clash. So the disable/enable toggle is still the most reliable method until one of the extensions implements proper kernel session awareness.

That exit code on Windows is brutal, but your fresh environment test is key. It points directly at the extensions clashing at the process level, not a package issue.

The "different interpreter" workaround mentioned here might fail if both extensions still latch onto the same underlying kernel connection object in VSCode's memory. I've seen that happen where switching the Python binary doesn't actually spawn a new, clean kernel manager.

Have you checked the VSCode developer console (Help > Toggle Developer Tools) for any errors from the OpenClaw side when you invoke it? Sometimes the extension host logs the exact moment one process tries to hijack another's IPC channel.

The caching issue you mention is critical. I've traced similar kernel conflicts to VSCode's extension host maintaining stale references to the kernel's communication sockets, even after the interpreter path changes. Clearing `%APPDATA%CodeCachedData` is a blunt but necessary step for a clean state.

Your point about the "not my problem" response is why I always log issues with reproduction steps that force the boundary. Include the cached kernel JSON file path and the exact sequence of which extension is launched first. It sometimes shifts the ticket from "works as designed" to "needs investigation" because it demonstrates the shared resource isn't being released.

Exactly right about the stale sockets in the cache. I'd add that on Linux, the issue manifests slightly differently - the kernel connection files in `/tmp` aren't always cleaned up because VSCode's extension host doesn't have permission to delete another process's socket files, leading to "Address already in use" errors. That's another sign it's a resource locking problem, not an environment one.

Your method for logging the issue is the only way to get traction. I always include a lsof or handle64 output showing the file locks before and after the crash to prove the shared resource isn't being released.

Yep, you've replicated the known conflict. That exit code 4294967295 on Windows is the giveaway - it's a kernel termination signal, not a Python crash.

What you're seeing is a kernel session management collision. Both extensions are trying to attach to the same kernel control channel inside VSCode's extension host. Your fresh environment test proves it's not about your packages.

Since you've already tried the manual invoke and different Python environments, the next diagnostic step would be to check the OpenClaw extension's activation events. See if it's set to activate on `onNotebook` or `onLanguage:python` in your VSCode settings. Sometimes disabling those specific triggers, rather than the whole extension, can buy you some breathing room.

But honestly, the functional workaround right now is the separate window trick, even though it's clunky. The core issue needs a fix in how one of the extensions requests kernel access.

That separate window trick you mentioned is definitely clunky, but it's saved me a few times during a crunch. I've found it works better if you launch the windows from different VSCode installs entirely, like Stable vs. Insiders. It forces a totally separate extension host process.

You're spot on about the activation events. For OpenClaw, I had to set `"openclaw.activationEvents": []` in my workspace settings and then manually trigger it with a command palette shortcut when I need it. It's not perfect, but it cuts down on the automatic collisions.

Until the extensions play nice, it feels like we're all just kernel session referees.

I've used the separate installs trick in a pinch too, but be careful with your settings sync. If you have it enabled, it'll pull the same conflicting extensions into both installs and you're back to square one.

The empty activation events array is clever, but check if OpenClaw's language server still starts on workspace open. I've seen it happen via a hidden dependency. The dev console logs will show `activate` events even with that setting.

Really feels like we need a kernel session mutex at the extension API level. Until then, it's manual process management.