Remote Control threads do not expose automation_update / automation tools while host Desktop can create heartbeats

Open 💬 1 comment Opened Jun 5, 2026 by bumbuboon

What issue are you seeing?

When controlling a Mac mini host from a MacBook via Codex Remote Control, the remote-controlled thread does not expose the automation_update / automation management tool, so Codex cannot create a heartbeat automation from that remote session.

The same host, account, workspace, and project can create heartbeat automations when used directly from the Codex Desktop app on the Mac mini.

This makes Remote Control behave differently from local Desktop for automation management: the host has working automations, but the remote-control session cannot create or update them.

Environment

Host:

  • macOS host: Mac mini, BumbuMac-mini-M1.local
  • Codex App: 26.602.30954 / bundle 3575
  • Codex CLI: codex-cli 0.135.0
  • Codex home: /Users/shojibumbu/.codex
  • Project/cwd: /Users/shojibumbu/workspace/obsidian

Controller:

  • MacBook using Codex Remote Control to connect to the Mac mini host
  • Same ChatGPT account/workspace as the host

What works locally on the host

From the Mac mini's Codex Desktop app, heartbeat automations can be created successfully. The host currently has active heartbeat automation files such as:

  • /Users/shojibumbu/.codex/automations/daily-ai-and-market-research-brief/automation.toml
  • /Users/shojibumbu/.codex/automations/obsidian-vault-daily-commit-and-push/automation.toml

Those files contain valid active heartbeat automations, for example kind = "heartbeat", status = "ACTIVE", and a target_thread_id.

What fails remotely

From a MacBook Remote Control session connected to the same Mac mini host and project, asking Codex to create a heartbeat using an automation-management skill fails because the automation_update tool is not available in that remote-controlled thread.

Tool discovery from that remote session did not expose automation_update; it exposed unrelated tools such as GitHub/Gmail connector tools. Because the official automation path depends on automation_update, the thread cannot create/update automations without falling back to raw file edits.

Local evidence from host logs/state

On the Mac mini host, ~/.codex/state_5.sqlite shows the Remote Control enrollment for the host. The host logs show thread starts from Codex Desktop, but remote-created/remote-controlled threads appear to have no dynamic tools injected in some cases.

Observed pattern in ~/.codex/logs_2.sqlite:

  • Local Desktop-started thread: app_server.client_name="Codex Desktop" with thread_start.dynamic_tool_count=12
  • Remote/control-created thread: app_server.client_name="Codex Desktop" with thread_start.dynamic_tool_count=0

In the failing remote session, tool_search for automation_update did not make the automation tool callable.

Expected behavior

A Remote Control session that is connected to a host where Codex Desktop can create automations should expose the automation management tool, or provide an explicit message explaining that automation management is not supported from Remote Control.

At minimum, thread heartbeat creation should work from Remote Control when:

  • the host Codex Desktop is running,
  • the host has working automations,
  • the user is signed into the same account/workspace,
  • and the remote-controlled thread is running on the host project.

Actual behavior

The host can create heartbeat automations locally, but the Remote Control session cannot because the automation tool is absent from the remote thread tool surface.

Related issues

This seems related to, but not identical to:

  • #23351: remote/mobile-started threads showed dynamic_tool_count=0 while Desktop-started threads had dynamic tools
  • #19747: Automations sidebar entry disappears even when automation capability exists locally
  • #19425: tool discovery succeeds but tools are not exposed to Desktop threads
  • #24007: Desktop automation editor/persistence layer differs from open-source automation_update protocol references

Why this matters

Remote Control is useful for always-on hosts such as a Mac mini. Users may want to start a long-running task remotely and ask Codex to set a heartbeat/follow-up automation for that same thread. Today this works only when operating the host Desktop app directly, not through Remote Control, even though the host itself supports the automation.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗