Cloud Storage Object Watch with Codex
One object is one run, so a bucket taking twelve deliveries a day is twelve short runs and a nightly load writing four hundred part files is four hundred of them. That arithmetic is the reason most teams aim the trigger at a manifest or a single prefix rather than at a whole bucket. Codex keeps each of those runs quick and small.
Watch it work before it's live
Run a staged conversation — no account needed. The agent handles it for real while a simulated world answers its tool calls; nothing touches real accounts, and nothing is actually sent.
partners/nordfrakt/2026-08-12/deliveries_0004.parquet
412 MB, written 04:07 UTC by the partner service account. Parts 0001 to 0003 landed between 04:02 and 04:06 at 380 to 430 MB each. The same prefix on the four previous days held six parts and a _MANIFEST file. No manifest has appeared for today.
Set up in minutes
Using this template drops you into a guided setup. It asks exactly this, nothing else:
Connect Google Cloud Storage
One sign-in. The agent acts through your account, scoped to what this template uses.
Connect Slack
One sign-in. The agent acts through your account, scoped to what this template uses.
Bucket rules
What a correct delivery looks like in this bucket - the prefixes and naming shape you expect, who sends what and roughly when, how large a normal drop is, how many pieces a full one contains or which manifest closes it, and who to name in Slack when a delivery goes wrong.
Runs on Codex
Preselected for this page — connect your Codex account during setup, or switch to NoClick's built-in models with one click.
Watch it handle a test run
A staged conversation against a simulated world — then it’s live.
Why Codex for this agent
Watch the manifest, not the parts
The object that closes a delivery is usually the only one worth a run. Parts can land unwatched and the completeness question still gets answered once, at the end.
Short runs by construction
Metadata for one object plus a listing of the same prefix over a few days is a small read, so the per object figure stays low even when the file itself is enormous.
Before you fork
Object names include customer identifiers. What reaches Slack?
The full path and file name, because that is the evidence the whole check rests on, so anything encoded into your object names travels into the channel you connect. It never opens an object, so nothing from inside a file can leave. Buckets whose paths carry personal data are the case for a private channel or a tightly scoped prefix.
Run it with a different agent
Put Cloud Storage Object Watch to work on Codex
Free to start. Guided setup, a test run against staged conversations, and it's live.