›_ Codex Issues
Codex Issues / #34946

Allow Scheduled tasks to target SSH-connected hosts and surface runs in the controlling Codex app

Open 💬 4 comments Opened Jul 23, 2026 by Jameslin-9880

What variant of Codex are you using?

Codex desktop app as the controlling client, connected to a remote host through an SSH connected host (not remote-control pairing). The controlled host runs Codex CLI/app-server (0.145.0 in the observed setup).

What feature would you like to see?

Allow native Scheduled tasks to select an SSH-connected host and a project on that host as the execution target. The controlling Codex app should provide the same schedule management, progress visibility, run history, and result delivery that it provides for local Scheduled tasks.

Current behavior
  • The controlling Codex app can open chats and run Codex work on an SSH-connected host.
  • The same remote host is not available as a target when creating a Scheduled task.
  • A Scheduled task cannot be created from a chat running on that SSH-connected host.
  • External host schedulers such as launchd, cron, or systemd can invoke codex exec, but their schedules, progress, failures, and run history are not represented in the controlling app's Scheduled view.
  • Installing and keeping a full desktop app running on the controlled host solely to obtain native scheduling defeats the purpose of a headless or remotely managed host.
Requested behavior
  1. Show eligible SSH-connected hosts in the Scheduled task execution-target picker.
  2. Allow selection of a remote project directory or isolated worktree on the selected host.
  3. Support both:
  • scheduled runs that return to an existing chat on that host; and
  • standalone runs that appear separately in Scheduled.
  1. In the controlling app, display the target host, project path, next run, queued/running/succeeded/failed/missed status, progress, final result, and run history.
  2. Let a scheduled run continue on the controlled host when the controlling app disconnects, provided the target host remains online and authenticated.
  3. Define explicit behavior for an offline target, missed runs, overlapping runs, retries, pause/resume, and cancellation.
  4. Do not require remote-control pairing or a native desktop app on the controlled host; a secure host-side Codex service/app-server should be sufficient.
Security and permissions
  • Clearly identify the target host and working directory before schedule creation.
  • Preserve the host's sandbox, network, filesystem, and organization policy boundaries.
  • Make host registration and schedule execution revocable.
  • Avoid copying SSH keys, repository credentials, or other host secrets to the controller.
  • Surface when a run cannot proceed because unattended permissions are insufficient.
Acceptance criteria
  • A desktop app connected to a host through SSH can create a Scheduled task targeting that host.
  • The schedule remains visible and manageable from the controlling app.
  • A run started while the controller is disconnected executes on the target host and becomes visible after reconnection.
  • Same-chat runs append their results to the selected chat; standalone runs appear in Scheduled.
  • The controlling app exposes useful progress and error information without requiring a separate SSH session to inspect logs.

Additional information

This combines two related but currently separate needs:

  • #8317 requests first-class scheduling and run management for CLI/headless workflows.
  • #23200 requests first-class support for always-on remote/headless hosts without requiring a desktop bridge.

This request focuses specifically on the missing integration between the desktop app's SSH connected-host control plane and native Scheduled execution targets.

No real hostname, username, IP address, private repository name, credential, or project path is included in this report.

View original on GitHub ↗

4 Comments

jkobject · 16 days ago

related to #26489 real missing ferature

Liaoyyyy · 16 days ago

I can reproduce a more confusing variant of this limitation in Codex Desktop.

Steps to reproduce

  1. Open Scheduled in Codex Desktop.
  2. Click Create.
  3. Select an SSH-connected remote project and its remote working directory.
  4. Ask Codex to create a recurring scheduled automation for that project.
  5. The resulting thread correctly shows the selected remote project, remote connection, and SSH host.
  6. However, the result is created as a normal Codex thread rather than an automation:
  • no Automation ID is generated;
  • no corresponding task appears in Scheduled;
  • the thread does not receive the automation create/update capability.

The selected remote filesystem, project files, project-specific skill, shell, and connected email tool are otherwise accessible from the thread. The missing part is specifically the automation control-plane registration step.

Expected behavior

Either:

  1. create a native Scheduled task targeting the selected SSH host and remote project; or
  2. reject or disable the unsupported remote target during task creation with a clear explanation.

The current behavior silently falls back to a normal remote thread. Because the flow begins under Scheduled → Create and preserves the selected remote project in the resulting thread, users can reasonably believe that the automation was registered even though no scheduled task exists.

This appears related to inconsistent exposure of the automation update tool described in #29128, but the user-visible reproduction here specifically starts from the Scheduled creation UI.

Contact: liao.yanjun@foxmail.com

RandnYC · 11 days ago

I can confirm this still reproduces on 2026-08-17 with an SSH-connected Codex Desktop project.

Environment

  • Controlling surface: Codex Desktop
  • Project classification returned by the app: projectKind: "remote"
  • Host classification: remote-ssh-discovered
  • Remote runtime: codex-cli 0.146.0
  • Private hostname, repository name/path, account identifiers, and screenshots are intentionally omitted.

Reproduction

  1. Open a normal project task targeting an SSH-connected remote Git repository.
  2. Ask Codex to create a recurring repository-maintenance task whose prompt invokes a project skill.
  3. The desktop app visibly has a working Scheduled page with existing scheduled tasks.
  4. The task's model instructions explicitly route scheduling requests to automation_update.
  5. Inspect the task's live tool catalog.

Actual behavior

  • No automation_update, scheduler, or recurring-task action is present.
  • Other Codex app dynamic tools are present and functional, including project and thread-management tools, so this is not a total loss of app tooling.
  • The agent cannot register anything in Scheduled and correctly refuses to emulate it with raw automation files, internal database edits, or system cron.
  • No scheduled task is created, even though the surrounding UI and instructions make the operation appear supported.

Expected behavior

Either:

  1. expose automation_update and allow the scheduled task to target the selected SSH-connected host/project; or
  2. fail closed at creation time with an explicit message that native Scheduled tasks cannot target SSH-connected projects.

The current state is especially confusing because the product UI exposes Scheduled tasks and the agent is instructed to call automation_update, but the corresponding tool is omitted only from the remote-project task's tool surface. This matches the silent normal-thread fallback described in the existing reproduction above.

creatorKoo · 7 days ago

+1 — this is exactly the workflow I need.

I use an always-on headless host through Codex's SSH connected-host feature. Interactive remote work already works well, but Scheduled tasks currently only let me choose the local machine or cloud, so I can't target that existing SSH host.

Ideally the SSH-connected host could be selected directly as the execution target, and scheduled runs would continue there even when the controlling Mac is offline. That would avoid having to build a separate cron/systemd-based automation path just for the same Codex workflow.