Feature request: allow existing automations to be run on demand

Summary

I’d like Codex automations to support an explicit “run now” / ad hoc trigger action for an existing automation, without waiting for its next scheduled recurrence.

Today, automations appear to support create/update/view/delete flows, but I don’t see an exposed way to manually trigger an existing automation immediately.

Motivation

When creating or editing an automation, it is useful to test it immediately:

• Verify the prompt behaves as expected.
• Confirm workspace/thread context is correct.
• Debug permissions or environment setup.
• Run a scheduled task early without changing its schedule.
• Avoid creating duplicate one-off automations as a workaround.

This would make automations easier to trust and iterate on.

Current Behavior

From the exposed automation_update tool schema, the supported modes appear to be:

• view
• create
• update
• delete
• suggested_create
• suggested_update

There does not appear to be a run, trigger, or run_now mode.

In the open-source repo, I found support for automation-related plumbing, but not a first-class ad hoc trigger:

• codex-rs/core/src/tools/handlers/tool_search.rs exposes automation_update as a deferred codex_app dynamic tool.
• codex-rs/app-server-protocol/src/protocol/v2/thread.rs supports thread_source, which can identify automation-originated threads.
• codex-rs/app-server-protocol/src/protocol/v2/turn.rs supports additional_context, including automation context.
• codex-rs/app-server/src/bespoke_event_handling.rs forwards dynamic tool calls to the host/client.

My read is that the Rust side supports automation-originated work, while the scheduler/automation manager may live in the Codex app layer.

Proposed Behavior

Add a supported way to trigger an existing automation immediately.

Possible API shape:

automation_update({
  mode: "run",
  id: "<automation-id>"
})

or:

automation_update({
  mode: "trigger",
  id: "<automation-id>"
})

Expected behavior:

• The automation runs once immediately.
• Its existing schedule remains unchanged.
• The run uses the same prompt, workspace/thread target, model, effort, and environment config as the saved automation unless explicitly overridden.
• The UI/API returns a thread id, run id, or status so the user can inspect the result.

Open Questions

• Should this be supported for both cron automations and heartbeat/thread automations?
• Should an ad hoc run create a new thread, resume the target thread, or depend on automation kind?
• Should users be able to override the prompt/model/cwd for a one-off run?
• Should “run now” be allowed for paused automations?
• Where should the source of truth live: Codex app scheduler, app-server protocol, dynamic tool schema, or all of the above?

Acceptance Criteria

• Users can manually trigger an existing automation.
• The saved schedule is not modified.
• The run is visible/inspectable like scheduled runs.
• Errors are surfaced clearly when permissions, workspace setup, or thread state prevent execution.
• Tests cover the exposed API/schema behavior and the expected routing behavior.

Willingness to Contribute

I’m interested in contributing an implementation if maintainers agree this fits the roadmap and can point me to the right ownership boundary.