GitHub, CI, an email rule, or your own application sends an event.
Environment Webhooks for Codex
Codex webhooks: let an important event start the work.
A GitHub review, CI failure, email rule, or application event can trigger a native Codex Turn in Sandpi. Use verified events instead of a five-minute polling loop, then return to the same durable workspace when the work is ready.
GitHub App signatures and custom bearer tokens keep the ingress controlled.
Filter, detect a state change, and debounce, batch, or queue the work.
Choose a new Session, a fixed Session, or a GitHub source-thread Session.
The inbound path
Give Codex a verified event, not an open HTTP port.
Sandpi owns the webhook ingress and turns an accepted delivery into a durable Automation run before it submits a native Codex Turn. Your Sandbox does not become a public process endpoint.
Outbound notification
A completed task can send a signal out.
Codex notification configuration is useful when an agent has finished and another system needs to hear about it.
Inbound automation
An external event can start the next Turn.
Environment Webhooks solve the opposite direction: a verified external system tells Sandpi when a Codex task should respond.
The event payload is treated as untrusted data, not as instructions. See how a Sandpi Environment keeps the workspace, terminal, and native session together.
Choose the context
An event can start fresh work or wake the right thread.
The useful question is not only what happened. It is which repository context and conversation should receive the event.
New Session
Start a clean investigation for each event.
Use a new Session when every alert deserves its own isolated task and result.Fixed Session
Keep recurring work in its established context.
Send a webhook to the durable Session already holding the repository, instructions, and investigation history.GitHub source thread
Keep one pull request or issue in one thread.
For GitHub events, Sandpi can map reviews, comments, and updates for the same pull request or issue to one durable Session.Respond without a storm
Do not turn every delivery into a separate agent run.
Event-driven work is only useful when it stays legible. Environment Webhooks separate trigger rules, cooldown behavior, and run admission so a noisy source does not become noisy work.
Match the event that matters
Filter before Codex spends a turn.
Allow only chosen event types, add field-level conditions, or run only when a tracked state changes.Absorb a burst
Debounce, throttle, or batch noisy systems.
Decide whether a burst should keep the first event, the latest event, or a bounded merged set before work begins.Keep the handoff accountable
Bound the queue and inspect the history.
Set pending and concurrent-run limits, then use delivery and run history to understand what was accepted, filtered, queued, or skipped.Start from the event
Replace the poll with a useful handoff.
A pull-request review arrives
A GitHub review, review comment, or issue update can start Codex with the verified event context. The same pull request or issue can keep using its own durable Session instead of creating a fresh conversation for every comment.
CI or a deployment reports a failure
Send a custom event from the system that already knows the build or deploy failed. Codex can inspect the repository and the event context instead of repeatedly polling a status endpoint for a change.
An important email becomes a development task
Use an email rule or automation service to turn a selected alert into a custom webhook. Sandpi is not an inbox connector; the mail system chooses what is important, then posts the verified event.
Webhooks and schedules are different tools
Use a Schedule for the clock. Use a Webhook for the change.
A nightly maintenance task belongs on a recurring Schedule. A pull-request review, CI failure, or selected alert belongs on an event trigger. Both can deliver work into the durable Environment that holds your Codex task.
Questions before you connect a source
Codex webhooks, without the ambiguity.
Does Sandpi expose my Codex Sandbox as a webhook server?
No. Sandpi receives and verifies the event at the Environment layer, records the delivery, applies its policy, and submits a native Codex Turn. The Sandbox process is not exposed as the webhook control plane.
Can an email trigger a Codex task?
Yes, when an email rule or automation service posts a selected message or alert to a custom Environment Webhook. Sandpi does not claim to be a direct inbox integration; the mail system decides what to forward.
Which GitHub events can start work?
The direct GitHub source supports pull requests, pull-request reviews and review comments, issues, and issue or pull-request comments. You choose the repositories and event types that matter.
What if the target Session is already busy?
A fixed Session admits one active Turn at a time. Configure the Webhook to queue and retry the event, or record it as skipped; new and source-thread Sessions also have bounded concurrency and pending-run limits.
Should I replace every Schedule with a Webhook?
No. Use a Schedule when time is the trigger, such as a daily maintenance prompt. Use a Webhook when another system knows a relevant event has happened.
Stop polling for a change