Improve Codex Manipulation Of Notebooks

[jlewi]

Some of the issues I've observed

• Codex ends up adding/modifying the wrong notebook

  • I think this happens if you switch tabs
  • I think our toolcalls might implicitly assume you are working with the current notebook so if you switch tabs while codex is working it messes things up

• codex gets cell syntax wrong

  • I think there are enums for cellType that it frequently gets wrong (uses an int not the string or vice versa)
  • This makes modifications very slow because it has to do multiple trials to get it correct

• Poor job searching Google Drive

I think we'd like to move away from multiple tool calls and just have a single toolcall to let codex execute code. We could then build out suitable libraries. These libraries could also be used by users.

How could we build a suitable sandbox to safely execute agentic code?

• Google Drive - restrict to readonly access via scopes
• Data exfiltration - Block network access except to Google
• Allow Read/Write to open notebooks - these are just read/writes to indexed DB
  • We could always make them undoable

https://github.com/runmedev/web/blob/main/docs-dev/design/0310_appkernel_sandbox.md

[jlewi]

Might make sense to start with manipulating/updating notebooks and leave Google Drive alone.
Then we just need to build out a TS library for manipulating notebooks. That should probably be built ontop of a low level library for reading/writing to IndexedDB. Then in our sandbox we can swap that out for a library which post-messages to the primary app.

[jlewi]

Example of the update cell error.

I found the failing cell (gd-guide-pending-table) and confirmed the runtime doesn’t provide console.table. I’m pulling that cell now and will replace it with a small text-table fallback that works in AppKernel JS.

I’m updating that code cell now: I’ll keep the same data logic, add a printTable fallback, and only call console.table when it actually exists.

The notebook API rejected my first patch because UpdateCells expects enum-style kind values, not string labels. I’ll quickly look up the correct CellKind numeric value and retry.

I confirmed CELL_KIND_CODE is enum value 2; I’m retrying the notebook update with numeric kind and then validating by reading the cell back.

The cell update is in place. I’m executing that one cell now to verify the console.table error is gone.