agent loop detected: install ipykernel, restart, fail, repeating the same steps

TL;DR

An agent that installs ipykernel, restarts, fails, and repeats is treating an environment problem as a transient one. After the second identical failure the agent must stop and diagnose: capture the pip install output (it usually shows the real error: no network, no compiler, permission denied), fix that, and only then retry. Cap the install-retry loop at 2 and make the failure report include the install log.

agent loop detected: install ipykernel, restart, fail, repeating the same steps

Use this when

• An agent's setup loop repeats install plus restart with identical failures.
• The pip install output scrolls past without being read.
• The environment is a fresh container or restricted machine.

Not for this skill when

• The install succeeds but the kernel still fails. That is a kernelspec problem.
• A human runs the loop manually. Read the pip output yourself.

Steps

1. Stop the loop and read the actual pip output from one attempt. Verify: you can quote the real error.
2. Fix the revealed cause (network/proxy for downloads, write permission for site-packages, compiler for builds). Verify: the underlying command works by hand.
3. Cap the agent's install retries at 2, then escalate with the install log attached. Verify: the third failure produces a report, not a retry.
4. Add a pre-flight: check network, writability, and python version before installing. Verify: the agent fails fast with the true cause.
5. Re-run the agent. Verify: setup either succeeds or reports the real blocker once.

Variant phrasings

agent install ipykernel loop

Short form. Read the pip output.

agent retry install kernel fail

The symptom phrasing. Cap at 2, then diagnose.

ipykernel install fails agent setup

General phrasing. The installer log has the answer.

Compatibility: Any agent bootstrapping python kernels. The diagnose-don't-retry rule is universal.

Why it happens

pip failures are almost never transient in these loops: no network stays no network, and permission denied stays permission denied. The agent retries because its plan says 'ensure ipykernel' and retry is its only recovery, while the diagnostic information it needs is in the install output it already has but never parses. Two attempts distinguish flakiness from determinism; beyond that, retry is just burning time.

Edge cases / pitfalls

• A retry cap without log capture turns a loop into a silent give-up. Capture the installer output always.
• Partial installs (pip died halfway) leave broken metadata. Clean and reinstall rather than retrying over them.
• The agent may be installing into the wrong python. Verify the target with which python in the agent's context.
• Offline environments need a wheelhouse or mirror. The fix is infrastructure, not more retries.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_67RYNLwRcvzYIElDY5KRyQ