Skip to content

fix(windows): give a starting kernel long enough to publish its ports - #1004

Closed
noahsabaj wants to merge 1 commit into
PrimeIntellect-ai:mainfrom
noahsabaj:fix/windows-kernel-port-timeout
Closed

fix(windows): give a starting kernel long enough to publish its ports#1004
noahsabaj wants to merge 1 commit into
PrimeIntellect-ai:mainfrom
noahsabaj:fix/windows-kernel-port-timeout

Conversation

@noahsabaj

@noahsabaj noahsabaj commented Aug 8, 2026

Copy link
Copy Markdown

Problem

A kernel that has not written resolved ports within five seconds is reported as broken:

Kernel did not resolve connection ports within 5000ms. stderr tail:
(empty)

The empty stderr tail is the tell. A kernel that actually failed says why; a kernel that is merely slow says nothing, because it is still starting.

On Windows five seconds is not a generous budget. The interpreter start alone costs more than on Linux, and several kernels coming up at once — a sharded test run, or a daemon opening sessions in parallel — pushes past it. On a full local run of the coding-agent suite, three separate suites failed this way, all with the same empty tail.

Fix

Fifteen seconds on Windows, unchanged elsewhere.

The wait loop already exits as soon as the kernel dies, so the longer budget cannot delay a genuine failure — a crashed kernel still reports immediately, with its stderr. It only stops a slow start being called a broken one.

Verification

Measured on the Windows branch where the kernel port is complete: with the old budget, kernel-agent-message-skill, kernel-agent-observe-skill, and ipython-bootstrap failed on a full sharded run; with this change, all three pass and the whole suite is green across the three shards.

Note for reviewers: the kernel suites cannot run on Windows on unmodified main, because bootstrap fails earlier at ensureKernelPythonUncached with "First-time setup needs internet to install uv, Python, ipykernel" — the venv interpreter gap that #663 and #695 address. That is why the measurement above comes from a branch with those fixes applied. This change is one constant and cannot affect that path.

biome, tsgo --noEmit, and the root npm run check pass.


🤖 Generated with Claude Code

Note

Extend kernel port resolution timeout to 15s on Windows

IPython kernels start more slowly on Windows, causing the previous 5s timeout to misreport a still-starting kernel as broken. The PORTS_RESOLVE_TIMEOUT_MS constant in index.ts is now set to 15,000 ms on Windows and unchanged at 5,000 ms elsewhere.

Macroscope summarized b7b6fc7.

A kernel start that has not written resolved ports in five seconds is reported
as a broken kernel. On Windows it is usually just a slow one: the interpreter
start alone costs more than on Linux, and several kernels coming up at once —
a sharded test run, or a daemon opening sessions in parallel — pushes past the
budget. Three suites failed this way on a full local run, all with the same
empty stderr tail, which is what a healthy-but-slow start looks like.

Fifteen seconds on Windows, unchanged elsewhere. The wait loop already exits as
soon as the kernel dies, so the longer budget cannot delay a genuine failure —
it only stops a slow start being called a broken one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@noahsabaj
noahsabaj force-pushed the fix/windows-kernel-port-timeout branch from 693d11f to b7b6fc7 Compare August 11, 2026 17:26

Copy link
Copy Markdown
Member

Hi, thanks for taking the time to contribute to Prime Agent! Since open sourcing the project, we’ve received far more pull requests than we can responsibly review and validate. Prime Agent runs directly on users’ machines, so we need to be deliberate about which changes we accept and how they are reviewed. Rather than leave a large backlog that we cannot meaningfully work through, we’re closing the current PR queue and moving to a discussion-first contribution process.

We have established new contribution guidelines to help us continue iterating on Prime Agent and better manage contributions from the community. Going forward, we won’t review unsolicited pull requests. Instead, please start with a GitHub Discussion. We’ll identify recurring bugs and feature requests, create Issues for work we want to pursue, and invite pull requests from maintainers or vouched contributors when implementation is ready. Please read the full process documented in our contribution guidelines.

While we’re closing this backlog, we’re still reviewing it at a high level to identify recurring bugs, useful ideas, and important problems that we should address ourselves. Thanks again for the time you put into this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants