Wait for cloud task

Codex Cloud does not currently provide an official public REST API. This callable uses undocumented ChatGPT backend endpoints that may change without notice.

codex.waitForCloudTask durably checks an existing task until it reaches a terminal state.

automations/wait-for-codex-task.automation.ts

import { automation, onHttpRequest, withPrerequisites } from "automate.ax"
import { codex } from "automate.ax/codex"

export default automation("Wait for Codex", () => {
  const request = onHttpRequest({ scope: "automation" })
  const completed = withPrerequisites(request, () => {
    const started = codex.startCloudTask({
      branch: "main",
      environmentId: "env_abc123",
      prompt: "Implement the requested change and validate it.",
    })
    return codex.waitForCloudTask({
      taskId: started.id,
      pollInterval: "5m",
      maxPolls: 36,
    })
  })

  // Publish the completed Codex status and pull requests.
})

taskId accepts a task ID or compatible signal, including codex.startCloudTask(...).id or codex.continueCloudTask(...).taskId. pollInterval defaults to "5m". maxPolls defaults to 36 and accepts up to 120. Optional second argument { account } defaults to the project binding and is reused for every status check. Automate.ax checks immediately, then performs each remaining check after a durable delay, so provider work can outlive any individual Lambda invocation. One reusable delivery route handles every check, so the plan stays the same size at every polling budget. Deliveries start independent roots, and correlation joins the terminal delivery with the initiating context. The result emits when the task leaves pending, including an explicit unknown state for an unrecognized provider state. It includes the prompt, turn history, attempts, messages, diff, branch, environment, and pull requests. The signal fails if the task remains pending for the complete polling budget or a provider request exhausts its retries.

codex.waitForCloudTask uses a hidden invocation trigger and introduces additional context roots. Scope literal starter actions to their initiating signal. In this example, withPrerequisites anchors both startCloudTask and the wait composition to the HTTP request.

Built-in triggers

Built-in actions

Runtime utilities

Integrations