Codex already lives in your terminal, a few keystrokes from a Sheets API client and a batch update. You have written that script. The difference between Codex on a Scratch folder and that script is that one shows you the diff first. The pass you want, sort four thousand free-text notes into six categories, is a judgment call per row that a script cannot make and a transaction you should not commit blind.
Scratch pulls the tab down, one local record per row. Codex edits the fields on your laptop and reports back like a code change; Scratch shows each cell as a diff; it writes only the cells you approve, one gridRange at a time. Untouched cells keep their values and their number formats.
How it works
- Scratch pulls your tabs into files. Sign in with Google and paste the URL of each spreadsheet Scratch may touch. Every tab becomes a table, row 1 becomes the field names, and a managed
Scratch IDcolumn in position A carries row identity so sorts and filters cannot scramble it. - Codex edits the rows. Point Codex at the Scratch folder and describe the change. It works the tab the way it works a codebase, and you read the result like a pull request. Sort every note into one of these six categories and leave the rest of the row alone. Codex works the files, never the live sheet.
- You review every diff and publish. Scratch shows each changed cell beside its original value. Approve what holds up, and Scratch writes only those cells through the Sheets API.
What people use it for
The data passes that turn into Apps Scripts because the grid only does find-and-replace:
- Sort a column of free-text notes into the dropdown categories you report on.
- Normalize company names, job titles, industries, and country codes across a whole export.
- Rewrite a product or content column for the entire catalog in one reviewed batch.
- Fill blank cells from what the rest of the row already says.
- Flag and merge duplicates that three people created in three styles.
Run it on 50 rows to settle the prompt, then let Codex work the tab.
Why not the Sheets API and a script?
A script does exactly what you spelled out and nothing smarter, and a batchUpdate lands in the live spreadsheet with no per-row review. Rerun it after a bad heuristic and you are restoring from version history. A Sheets MCP server has the same shape: a live write path, no diff, nothing to reject.
Scratch gives Codex the same full read and write access, but against a local copy, and pulls the publish step out for you. Codex can change any cell; only you commit it. Every published change is reversible per row.
What Codex edits in Google Sheets
- Text, number, checkbox, and dropdown columns
- Dates, datetimes, currency, and percentages, as typed values rather than strings
- New rows, appended below your data
- Row deletions, applied bottom-up so the rows above never shift underneath
Field names come from row 1: reordering columns keeps the field, renaming a header creates a new one, and empty-headered columns are invisible to Scratch. Cells hold scalars, so a list or object fails the publish loudly instead of being stringified. For the full picture, see Scratch for Google Sheets.
Questions people ask
Which spreadsheets can it reach?
Only the ones whose URLs you pasted. The OAuth scope is exactly spreadsheets with no Drive scope, so Scratch cannot enumerate your files, browse folders, open a spreadsheet you did not hand it, or delete anything. Edit the list later from Edit Connection.
Does it clobber formatting or untouched columns?
No. Writes are per cell, so anything nobody approved keeps its value and its number format. Validation, checkboxes, and date formats stay as you set them.
What is the Scratch ID column for?
Row identity. Row position is not stable under a sort, so Scratch manages one column headed Scratch ID in position A and stamps a short id into it, identified by developer metadata so it survives reorders. Delete or move it and the pull stops with an error and a recovery recipe rather than guessing which row is which.
Can I roll a change back after it publishes?
Yes, per row. Every published change is reversible from Scratch, and the original value sits beside the rewrite until you pick one.
Does it batch well on a few thousand rows?
Yes. Reads come back typed and unformatted, and writes go out RAW, so there is no locale re-parsing in either direction. Publish batches stay deliberately small: the Sheets API has no conditional writes, so a concurrent human reorder mid-publish is the one hazard worth avoiding.
How do I watch it run on my own sheet first?
Pull one tab, run the prompt on 50 rows, and read the diff before anything publishes. Nothing reaches Google until you approve it.
See it on your own sheet
Book a 30-minute demo on your own spreadsheet →, or try Scratch free and run the first pass yourself.