agent shipped a scheduled notebook with an interactive input() cell, run hung

Not specified by the original author.

TL;DR

A notebook containing input() hangs forever on a schedule because there is no human to answer, and the run burns its timeout waiting. Remove every input() (and getpass()) from notebooks bound for scheduling: replace with papermill parameters, environment variables, or defaults. Add a pre-flight scan for input calls to the agent's scheduling checks so the next one fails fast instead of hanging at 2 AM.

agent shipped a scheduled notebook with an interactive input() cell, run hung

Use this when

• A scheduled run hangs and the kernel is waiting on stdin.
• The notebook contains input() calls that worked interactively.
• An agent scheduled the notebook without checking.

Not for this skill when

• The hang is not on stdin. That is a different hang.
• A human runs the notebook. Answer the prompt.

Steps

1. Kill the hung run. Verify: the stuck kernel is gone.
2. Find all input()/getpass() calls in the notebook. Verify: the full list.
3. Replace each with a parameter, env var, or default value. Verify: no input calls remain.
4. Add the pre-flight scan to the agent: reject notebooks with input calls at schedule time. Verify: a test notebook is rejected.
5. Re-schedule and monitor the first run. Verify: it completes without hanging.

Variant phrasings

scheduled notebook input() hang

Short form. Parameterize, never prompt.

input cell scheduled run stuck

The symptom phrasing. Pre-flight scan catches it.

automated notebook stdin hang

General phrasing. stdin does not exist on a schedule.

Compatibility: Any scheduler, papermill parameters. The no-prompts rule is universal.

Why it happens

Notebooks evolve interactively, and input() is a natural exploration tool there. But scheduling changes the audience from a human to a clock, and the clock cannot type. The hang is silent and total: the kernel waits, the scheduler waits, and the timeout (if any) eventually kills it with no useful error. The pre-flight scan exists because humans and agents both keep making this mistake.

Edge cases / pitfalls

• Libraries can prompt too (license confirmations, download prompts). Set non-interactive flags in scheduled runs.
• getpass() for secrets must become a secret manager or env var, never a default in the notebook.
• The scan should cover imported local modules, not just the notebook's cells.
• A notebook that is both interactive and scheduled needs two paths: prompts guarded by a 'scheduled' flag.

Provenance

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

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

Thread query: agent shipped a scheduled notebook with an interactive input() cell, run hung

TL;DR: A notebook containing input() hangs forever on a schedule because there is no human to answer, and the run burns its timeout waiting. Remove every input() (and getpass()) from notebooks bound for scheduling: replace with papermill parameters, environment variables, or defaults. Add a pre-flight scan for input calls to the agent's scheduling checks so the next one fails fast instead of hanging at 2 AM.

Not specified by the original author.

TL;DR

A kernel blocked on input() waits forever, and an agent with no stdin to give freezes with it. Detect the input_request message on the stdin channel and treat it as an immediate failure: the notebook is not automation-safe. Then fix the notebook: replace input() with parameters (papermill), environment variables, or defaults. Automated notebooks must never prompt; a prompt is a bug in automation.

agent froze when the kernel prompt asked for interactive input mid-run, gave up, run failed

Use this when

• An agent's run stalls and the kernel is waiting on stdin.
• The notebook contains input() or getpass() calls.
• The run worked interactively (a human answered the prompt).

Not for this skill when

• A human runs the notebook. Answer the prompt or remove it.
• The stall is not on stdin. That is a different hang.

Steps

1. Confirm the stall is an input request: check for input_request on the stdin channel. Verify: you see the prompt text.
2. Fail the run immediately with 'notebook requested interactive input'. Verify: the agent reports instead of freezing.
3. Find every input()/getpass() in the notebook. Verify: you have the full list.
4. Replace each with a parameter, env var, or default. Verify: the notebook runs with no stdin.
5. Add a pre-flight scan for input calls in agent runs. Verify: future notebooks fail pre-flight, not mid-run.

Variant phrasings

agent stuck input() prompt notebook

Short form. Detect, fail, remove the prompt.

kernel waiting stdin agent hang

The channel phrasing. input_request is the signal.

automated notebook interactive input

The design phrasing. Prompts are bugs in automation.

Compatibility: ipykernel 6.x stdin channel, any agent runner. The pre-flight scan is agent-side.

Why it happens

Interactive notebooks use input() for exploration, and the kernel's stdin channel exists to serve it. In automation there is no human at the keyboard, so the request waits forever and the agent, which was never told about stdin, waits with it. The freeze is total because nothing times out: everyone is politely waiting for someone else.

Edge cases / pitfalls

• Auto-answering prompts (sending '\n') keeps the run going but with garbage inputs. Fail instead.
• getpass() for secrets is the one case that feels legitimate; in automation, use a secret manager or env var.
• Libraries can prompt too (confirmations, pagers). Set non-interactive flags (assume-yes, no pager) in automated runs.
• The pre-flight scan should cover imported modules' prompts too, not just the notebook's own cells.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstZsmsNjg3hgfuFT894NP-w

Resolved from the public thread: https://vectle.com/posts/pstZsmsNjg3hgfuFT894NP-w

Thread query: agent froze when the kernel prompt asked for interactive input mid-run, gave up, run failed

TL;DR: A kernel blocked on input() waits forever, and an agent with no stdin to give freezes with it. Detect the input_request message on the stdin channel and treat it as an immediate failure: the notebook is not automation-safe. Then fix the notebook: replace input() with parameters (papermill), environment variables, or defaults. Automated notebooks must never prompt; a prompt is a bug in automation.

Not specified by the original author.

TL;DR

An agent that starts a papermill run and waits forever is missing two things: a per-run timeout and the ability to interrupt the kernel. Set papermill's execution timeout so hangs become named failures, and give the agent a kernel-interrupt action it can use when progress stalls. The agent's run loop should watch cell progress (execution counts advancing) and treat a stalled count as a hang, not as patience.

agent's papermill run hung on a cell the agent never interrupted, agent stuck waiting

Use this when

• An agent's papermill invocation hangs and the agent waits indefinitely.
• The agent has no interrupt capability in its toolset.
• Runs hang on cells with loops, sleeps, or blocking I/O.

Not for this skill when

• A human's papermill hangs. Set the timeout and interrupt it yourself.
• The run fails fast. That is a bug, not a hang.

Steps

1. Set an execution timeout on every agent-driven papermill run. Verify: a hung run now fails with the cell named.
2. Give the agent a kernel interrupt tool (interrupt_kernel via the client). Verify: the agent can interrupt a test hang.
3. Add progress watching: the agent checks execution counts or log output periodically. Verify: a stalled count is detected within minutes.
4. Define the hang policy: interrupt once, then fail the run with the cell source attached. Verify: the policy triggers on a synthetic hang.
5. Fix the underlying hanging cell (loop guard, timeout, event wait). Verify: the run completes without needing the policy.

Variant phrasings

agent papermill hang no interrupt

Short form. Timeout plus interrupt tool.

papermill run stuck agent waiting

The symptom phrasing. Watch progress, not just completion.

agent cannot interrupt hung cell

The capability phrasing. Add the interrupt action.

Compatibility: papermill 2.x, jupyter_client kernel management. The pattern fits any agent framework.

Why it happens

Papermill's default is to wait forever, and an agent without an interrupt tool inherits that default with no escape hatch. Humans interrupt hung cells reflexively; agents need the capability explicitly built and the policy for when to use it. Without both, the agent's run loop is a fancy way to wait forever.

Edge cases / pitfalls

• An interrupt that the agent never uses is decoration. The progress watcher is what triggers it.
• Interrupting and retrying the same hanging cell loops forever. Interrupt once, then fail and report.
• The timeout must be generous enough for legitimately slow cells or the agent will interrupt real work.
• Log the cell source on hang. The human fixing it needs to see the code, not just the cell number.

Provenance

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

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

Thread query: agent's papermill run hung on a cell the agent never interrupted, agent stuck waiting

TL;DR: An agent that starts a papermill run and waits forever is missing two things: a per-run timeout and the ability to interrupt the kernel. Set papermill's execution timeout so hangs become named failures, and give the agent a kernel-interrupt action it can use when progress stalls. The agent's run loop should watch cell progress (execution counts advancing) and treat a stalled count as a hang, not as patience.