agent broke the notebook when it tried to execute a cell with missing input file

Not specified by the original author.

TL;DR

An agent that executes a cell referencing a file that does not exist gets a loud FileNotFoundError at best and a half-mutated notebook at worst. Give the agent a pre-flight: before executing, resolve every input path the notebook references and fail fast with the missing list if any are absent. Never let the agent 'try it and see'; the try can have side effects before the missing file is even reached.

agent broke the notebook when it tried to execute a cell with missing input file

Use this when

• An agent's run fails on FileNotFoundError for an input the notebook expects.
• The notebook was moved, or the data lives elsewhere in automation.
• Cells before the failure had side effects.

Not for this skill when

• The file exists but is unreadable. That is permissions.
• A human hits the missing file. Fix the path yourself.

Steps

1. Stop the run and assess: which cells executed before the failure, and did they have side effects? Verify: you know the blast radius.
2. Build the pre-flight: the agent scans cell sources for file references and checks existence. Verify: a test notebook with a missing file fails pre-flight.
3. Resolve paths against the run's working directory explicitly (no cwd assumptions). Verify: relative paths resolve correctly.
4. On missing inputs, the agent reports the missing list and stops before executing anything. Verify: zero cells run on missing inputs.
5. Fix the data placement or the paths, then re-run. Verify: pre-flight passes and the run completes.

Variant phrasings

agent missing input file execution

Short form. Pre-flight before executing.

notebook filenotfounderror agent run

The error phrasing. Validate inputs first.

agent execute cell missing data file

General phrasing. Fail fast, execute nothing.

Compatibility: Any notebook runner. The pre-flight is agent-side static analysis.

Why it happens

Notebooks assume their data is where the author left it, and agents execute where they are told, and those two places differ constantly in automation. Executing before validating means the failure lands mid-notebook, after earlier cells may have written outputs, created files, or mutated state. Pre-flight moves the failure to before anything runs, when it is cheap and clean.

Edge cases / pitfalls

• Static scanning misses dynamically constructed paths (f-strings, config files). Also check config-declared inputs.
• A pre-flight that only checks existence misses permission problems. Check readability too.
• The working directory of the agent's kernel may differ from the notebook's directory. Resolve explicitly.
• Do not let the agent 'fix' missing inputs by creating empty files. That converts a clear error into silent wrong results.

Provenance

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

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

Thread query: agent broke the notebook when it tried to execute a cell with missing input file

TL;DR: An agent that executes a cell referencing a file that does not exist gets a loud FileNotFoundError at best and a half-mutated notebook at worst. Give the agent a pre-flight: before executing, resolve every input path the notebook references and fail fast with the missing list if any are absent. Never let the agent 'try it and see'; the try can have side effects before the missing file is even reached.

Not specified by the original author.

TL;DR

A cell that deletes the CSV it reads from will succeed once and then fail forever, and an agent that re-runs it loops on a file that no longer exists. This is a data-safety bug first and a loop bug second: destructive operations must be guarded (check the file exists, refuse to delete inputs, write to a separate output path). Fix the cell so re-execution is safe, then fix the agent to stop retrying destructive failures blindly.

agent loop detected: re-executed a cell that deletes the source csv it reads from, restore failed

Use this when

• An agent re-runs a cell that deletes or overwrites its own input.
• The source file is gone and cannot be restored.
• The loop is: run, file missing, retry, file still missing.

Not for this skill when

• The file was deleted by a human. Restore from backup or version control.
• The cell fails for other reasons. Debug those directly.

Steps

1. Stop the agent immediately to prevent further damage. Verify: no more executions are running.
2. Assess the data loss: check backups, version control, or the source system for the CSV. Verify: you know whether it is recoverable.
3. Rewrite the cell: never delete inputs; write outputs to a separate path; guard with existence checks. Verify: re-running the cell is safe.
4. Add the agent rule: destructive operations require explicit confirmation and are never retried automatically. Verify: the policy is in the agent's runbook.
5. Restore the data from backup and re-run. Verify: the run completes without touching the source.

Variant phrasings

agent deleted input file loop

Short form. Guard destructive cells.

cell deletes its own input csv

The bug phrasing. Separate input and output paths.

agent re-execution data loss

The safety phrasing. Never auto-retry destructive ops.

Compatibility: Any notebook runner. The guard pattern is language-agnostic.

Why it happens

Notebooks mix exploration with file operations, and a cleanup line that made sense once (remove the raw file after processing) becomes a landmine under an agent that re-executes freely. The first run deletes the input; every later run fails on the missing file; the agent retries because retry is its hammer. The deeper failure is that nothing marked the operation as destructive and non-retryable.

Edge cases / pitfalls

• This vertical's framing rule applies: agents must never silently delete user data. Deletion needs explicit user confirmation.
• Backups are the only real safety net. Version the inputs or keep the raw data immutable.
• A 'restore failed' means the damage is done. The lesson goes into the runbook, not just the cell.
• Audit other cells for the same pattern (overwrite-in-place, delete-after-read). Fix them all.

Provenance

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

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

Thread query: agent loop detected: re-executed a cell that deletes the source csv it reads from, restore failed

TL;DR: A cell that deletes the CSV it reads from will succeed once and then fail forever, and an agent that re-runs it loops on a file that no longer exists. This is a data-safety bug first and a loop bug second: destructive operations must be guarded (check the file exists, refuse to delete inputs, write to a separate output path). Fix the cell so re-execution is safe, then fix the agent to stop retrying destructive failures blindly.

Not specified by the original author.

TL;DR

Colab's Drive mount is a per-session OAuth grant, so it expires and every path under the mount becomes file-not-found on the next run. Re-run the mount cell to re-authenticate for interactive use, but for agent pipelines stop depending on the mount: download inputs to the Colab VM or a bucket at run start and write outputs back explicitly. A pipeline that assumes the mount persists across sessions will break on exactly the schedule you cannot control.

agent pushed a notebook to colab but the drive mount expired: file not found

Use this when

• A Colab notebook that read from Drive yesterday now raises file-not-found on the same paths.
• An agent's scheduled Colab run fails at the first file read with the mount point missing.
• Re-running the mount cell fixes it temporarily, then it breaks again later.

Not for this skill when

• File reads fail on a local Jupyter server. That is a local path problem, not a mount-expiry problem.
• Cells fail for code or import reasons with Drive mounted fine. That is an execution bug.

Steps

1. Confirm the mount is the problem: list the mount point directory. Expected: it is empty or missing, while the mount cell has not been re-run this session.
2. For interactive recovery, re-run the Drive mount cell and complete the OAuth flow. Expected: the mount point lists your Drive files again.
3. For the agent pipeline, add an explicit fetch step at the top: copy needed inputs from Drive (or better, from a bucket or repo) into the VM's local disk. Expected: the notebook reads from local paths that do not depend on the mount.
4. Change all writes to go to explicit destinations: save outputs to the VM disk, then upload to Drive or the bucket at the end. Expected: results survive even if the mount drops mid-run.
5. Remove hard-coded /content/drive paths from the notebook logic; take input and output roots as parameters. Expected: the same notebook runs mounted or unmounted.
6. Schedule a periodic check: if the pipeline must use the mount, the agent should verify the mount point is populated before doing work and fail fast with a clear message otherwise. Expected: mount expiry becomes a loud, fast failure instead of a confusing file-not-found deep in the run.

Tool compatibility

Google Colab hosted runtime; drive mount via the standard mount cell; Python 3.10/3.11 Colab images.

Variant phrasings

colab drive mount expired file not found

The direct phrasing. Re-authenticate, then remove the mount dependency from automation.

google drive not mounted colab notebook error

The missing-mount phrasing. The mount is per-session and must be re-established.

colab scheduled notebook drive disconnected

The scheduling phrasing. Scheduled Colab work should not depend on interactive OAuth mounts.

Why it happens

The Colab Drive mount is not a filesystem; it is a FUSE view backed by an OAuth token tied to the browser session that created it. Sessions end, tokens expire, and VMs get recycled, so the mount is inherently ephemeral. Notebooks that treat Drive paths as stable local paths work fine in a single interactive sitting and then fail the moment anything crosses a session boundary, which is exactly what agent-scheduled runs do. The robust pattern inverts the dependency: treat the VM as the workspace and Drive as an import/export endpoint touched only at the edges of the run.

Edge cases / pitfalls

• Re-authenticating inside an agent loop requires interactive OAuth, which agents cannot complete. Never design an unattended flow around re-mounting.
• Large Drive datasets copied on every run waste time and quota. Cache them on a bucket or use Colab's local disk cache across cells within one session.
• Paths under the mount differ between users' Drives. Parameterize paths even for interactive shared notebooks.
• Colab VM disks are also ephemeral across sessions. 'Local disk' means within one session; persist results outward at the end of every run.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AdTQEWCxW-KI1-krqYg2Ow

Resolved from the public thread: https://vectle.com/posts/pst_AdTQEWCxW-KI1-krqYg2Ow

Thread query: agent pushed a notebook to colab but the drive mount expired: file not found

TL;DR: Colab's Drive mount is a per-session OAuth grant, so it expires and every path under the mount becomes file-not-found on the next run. Re-run the mount cell to re-authenticate for interactive use, but for agent pipelines stop depending on the mount: download inputs to the Colab VM or a bucket at run start and write outputs back explicitly. A pipeline that assumes the mount persists across sessions will break on exactly the schedule you cannot control.