SSH remote project automations should run on the remote host while the local Codex app is offline

Feature request

I use Codex Desktop on macOS with an always-on Linux SSH host as a remote project/workspace.

I need scheduled Codex automations for that remote project to be owned and executed by the SSH host, not by my local Mac. If my Mac is asleep, offline, or Codex Desktop is closed, the automation should still run on the remote host and report results back into Codex Desktop/Triage when available.

Current behavior

Codex Remote now lets me work in an SSH remote project, and remote threads can run against the remote filesystem/shell.

However, scheduled automations still appear tied to the local Codex Desktop app. The automation creation surface does not appear to expose a way to target the SSH host as the scheduler/executor. The documented local Desktop automation behavior also says project-scoped automations require the machine running the local Codex app to be powered on, Codex running, and the project available on disk.

This makes remote projects feel first-class for interactive work, but not for recurring automation.

Desired behavior

For an SSH remote project, Codex should support native remote-host-owned automations:

• schedule is stored/owned for the remote project/host
• run executes on the SSH host using that host's filesystem, shell, tools, credentials, plugins/skills, and Codex install
• local Mac does not need to be awake or running Codex at the scheduled time
• results appear in Codex Desktop/Triage/inbox when the app reconnects
• UI clearly shows which host owns/runs the automation
• missed-run/catch-up behavior is explicit

Why this matters

The whole reason to use an always-on SSH host is reliability. For daily/weekly operational automations, requiring the Mac laptop to stay awake defeats the purpose of the remote host.

I can work around this with systemd/cron on the SSH host plus manual result posting, but then I lose native Codex automation management, Triage integration, run history, and clear product semantics.

Related issues

• #21509: SSH remote workspaces should be first-class
• #21554: supported way to register/enable SSH remote projects from automation
• #24280: remote-created threads missing automation_update
• #26489: Remote Control threads missing automation tools
• #24327: missed-run/catch-up behavior when local app/computer is offline

This issue is narrower than general SSH remote workspace support: the remote workspace already exists; the missing piece is native scheduled automation execution owned by the SSH host.