Repository navigation
Remote Control threads do not expose automation_update / automation tools while host Desktop can create heartbeats #26489
Description
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/ bundle3575 - 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"withthread_start.dynamic_tool_count=12 - Remote/control-created thread:
app_server.client_name="Codex Desktop"withthread_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:
- Remote mobile-started and CLI-started threads are not listed in the mobile app for resume #23351: remote/mobile-started threads showed
dynamic_tool_count=0while Desktop-started threads had dynamic tools - Codex desktop: Automations sidebar entry disappeared after GPT-5.5 update, language and quick action menu not working #19747: Automations sidebar entry disappears even when automation capability exists locally
- Custom stdio MCP server discovered by /mcp but tools not exposed to Desktop threads #19425: tool discovery succeeds but tools are not exposed to Desktop threads
- Codex Desktop automations overwrite custom provider model IDs after view/edit #24007: Desktop automation editor/persistence layer differs from open-source
automation_updateprotocol 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.
Activity
github-actions commentedon Jun 5, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
jkobject commentedon Aug 12, 2026
upvoting this as a real missing feature for me
exevil commentedon Aug 20, 2026
Still reproducible with Mac-to-Mac Remote Control. Automation tools are available when I use Codex directly on the Mac mini, but remote threads from my MacBook do not expose
automation_update. I cannot create, inspect, update, pause, resume, or delete automations on the remote host.Submitted through
/feedback:01a01f02-96ff-7e61-885f-fd2d86bc12c1(no logs attached).pontuslagerberg commentedon Sep 14, 2026
Temporary workaround: I built a per-task
launchdheartbeat that runs every five minutes and usescodex exec resume <thread-id>to continue the same persisted Codex task with its original context. It prevents overlapping runs and unregisters itself once the task reaches its terminal condition.This makes “loop,” CI/PR babysitting, deployment waits, and long-running process monitoring workable on an always-on Mac mini, but it is not a substitute for native thread automations. The agent cannot create this fallback from the affected Remote/VS Code task without extra local setup, and it lacks the app’s native automation UI, state, and guarantees.
This is important to fix because autonomous loop prompting depends on the agent being able to wake itself and continue work through completion. Without that capability, users must repeatedly nudge an otherwise capable long-running agent.
mbtz commentedon Sep 21, 2026
Still reproducible in a remote-host Codex desktop session on September 21, 2026. Please explain why remote sessions lack these capabilities and enable the same automation and task-management tools available in direct sessions on the host, subject to the same permissions.
The current session's complete callable tool registry was checked, rather than relying only on the initially displayed tool list:
automation_update/mcp__codex_app__automation_update.create_thread,fork_thread,send_message_to_thread, andhandoff_threadwere also absent.list_threads,read_thread,wait_threads,list_projects,create_worktree,get_handoff_status,set_thread_title, andset_thread_archived. This is a partially exposed app tool surface, not a complete loss of app connectivity.The user reports that sessions opened directly on the same host have the missing capabilities. That comparison is user-reported; the missing tools above were verified in this remote session.
Concrete impact: an explicitly authorized PR-maintenance workflow could inspect feedback, fix code, run verification, and push the changes, but could not schedule its required five-minute, same-task follow-up to monitor CI and new review feedback. Task creation and messaging were unavailable as well, limiting coordination. The workflow stops at scheduling even though the remote session can already perform the underlying repository work.
This feels like an unnecessary and confusing product limitation. Connecting remotely should preserve the host's supported coordination and scheduling capabilities. Please:
Related task-management report: #26907. This comment adds current reproduction evidence and the concrete scheduling impact to the existing report rather than opening a duplicate.
kendonB commentedon Oct 10, 2026
Still not working (except awkwardly through dot)