Remote-created Codex Desktop threads on connected host do not receive automation_update/load_workspace_dependencies

1. Feedback ID

019e4c10-cadb-7e70-8bf8-38245507bc2f

2. Product

Codex Desktop App / Remote Control / app-server thread/start dynamic tool provisioning.

3. Environment

• Host: always-on Mac Mini running Codex Desktop
• Client: MacBook Pro using the Codex remote workflow against the Mac Mini host
• Host project path: ~/Documents/Codex/projects/business-intake-task-system
• Codex Desktop app/server version observed in logs: 26.519.41501
• CLI/session version: codex-cli 0.133.0-alpha.1
• Platform: macOS / Darwin / Apple Silicon

Hostnames, user account paths, raw logs, databases, auth files, and unrelated prompt content are intentionally not included here.

4. Summary

Brand-new Codex Desktop threads created locally on the Mac Mini host receive the expected built-in Codex app dynamic tools:

• codex_app.automation_update
• codex_app.read_thread_terminal
• codex_app.load_workspace_dependencies

Brand-new threads created from the MacBook Pro remote workflow against the same Mac Mini host and same project receive only:

• codex_app.read_thread_terminal

If a thread is created locally on the Mac Mini first and then continued from the MacBook Pro, the full tool set remains available. So remote continuation works, host-local thread creation works, but brand-new remote thread creation appears to persist a reduced dynamic-tool set at thread creation time.

5. Steps to reproduce

1. On a Mac Mini host running Codex Desktop, open a new project thread locally for a project path such as ~/Documents/Codex/projects/business-intake-task-system.
2. Confirm the thread has codex_app.automation_update, codex_app.read_thread_terminal, and codex_app.load_workspace_dependencies.
3. From a MacBook Pro, use the Codex remote workflow to create a brand-new thread on the same Mac Mini host and same project path.
4. Inspect the new remote-created thread's dynamic tools.
5. Separately, create a thread locally on the Mac Mini first, then continue that same thread from the MacBook Pro.

6. Expected behavior

A brand-new remote-created thread on a connected host should receive the same built-in Codex app dynamic tools as an equivalent host-local thread for the same project.

If remote-created threads are intentionally not automation-capable, Codex should clearly label them as such and provide an action to create or open an automation-capable host-local thread.

7. Actual behavior

Remote-created brand-new threads look like normal user project threads but are persisted with only codex_app.read_thread_terminal. They do not receive codex_app.automation_update or codex_app.load_workspace_dependencies, so they cannot create or update Codex automations.

8. Confirmed PASS cases

Mac Mini direct via deep link

• Session: 019e5690-baaa-7161-8e15-5b3cbe023ffa
• Dynamic tools:
• codex_app.automation_update
• codex_app.read_thread_terminal
• codex_app.load_workspace_dependencies
• App-server indicator: connection_id=0
• Heartbeat/thread permission state: present in .codex-global-state.json

Mac Mini direct via normal Codex App UI new thread

• Session: 019e5694-641d-79a3-9447-54f86074e996
• Dynamic tools:
• codex_app.automation_update
• codex_app.read_thread_terminal
• codex_app.load_workspace_dependencies
• App-server indicator: connection_id=0
• Heartbeat/thread permission state: present

9. Confirmed FAIL cases

MacBook Pro remote workflow, brand-new thread on the Mac Mini host

• Session: 019e5697-260c-7d73-8941-4db90e80b7e6
• Dynamic tools:
• codex_app.read_thread_terminal
• Missing:
• codex_app.automation_update
• codex_app.load_workspace_dependencies
• App-server indicator: connection_id=12
• Heartbeat/thread permission state: absent

Second MacBook Pro remote-created failing-pattern thread

• Session: 019e56fe-b398-7c32-8768-2f3e656d0828
• Dynamic tools:
• codex_app.read_thread_terminal
• Missing:
• codex_app.automation_update
• codex_app.load_workspace_dependencies
• App-server indicator: connection_id=23
• Heartbeat/thread permission state: absent

10. Remote continuation result

A Mac Mini-created thread was continued from the MacBook Pro:

• Session: 019e5690-baaa-7161-8e15-5b3cbe023ffa
• Dynamic tools remained:
• codex_app.automation_update
• codex_app.read_thread_terminal
• codex_app.load_workspace_dependencies

This shows the MacBook Pro remote client can continue and use an automation-capable thread. The failure is specific to brand-new remote thread creation.

11. Evidence

• state_5.sqlite thread rows are materially identical across pass/fail for cwd, source, thread_source, model, sandbox, approval mode, CLI version, and memory mode.
• state_5.sqlite thread_dynamic_tools differs:
• host-local created threads: 3 tools
• remote-created threads: 1 tool
• Session JSONL session_meta.dynamic_tools differs on the first session_meta line, so the mismatch exists at or before session creation.
• logs_2.sqlite shows both paths using rpc.method=thread/start and rpc.transport=stdio with client_name=Codex Desktop and client_version=26.519.41501.
• The visible differentiator is app-server connection identity:
• host-local creation: connection_id=0
• remote new-thread creation: nonzero remote connection IDs such as connection_id=12 and connection_id=23
• .codex-global-state.json heartbeat-thread-permissions-by-id has entries for host-created passing threads but not for remote-created failing threads.
• No log evidence showed automation_update being denied or filtered by entitlement, policy, sandbox, or approval settings.

12. Important negative findings

• source=vscode is not causal. Passing and failing threads both report source=vscode.
• GitHub Copilot Chat appears unrelated.
• No active Codex/OpenAI/ChatGPT VS Code extension or bridge was found during inspection.
• VS Code was not running during inspection.
• Remote continuation does not strip automation_update.

13. Suspected root cause

The remote thread/start path appears to skip or use a reduced built-in dynamic-tool provisioning branch. It attaches read_thread_terminal but omits automation_update and load_workspace_dependencies, and it does not seed the same heartbeat/thread permission state that host-local thread creation seeds.

14. Workaround

Create the thread locally on the Mac Mini first, using either the Codex App UI or a deep link like:

open 'codex://threads/new?path=/Users/<user>/Documents/Codex/projects/business-intake-task-system'

Then continue that same thread from the MacBook Pro. Remote continuation preserves automation_update.

15. Scrubbed local evidence available

I can provide scrubbed excerpts from the relevant thread_dynamic_tools, session_meta.dynamic_tools, and app-server log rows if maintainers want them. I am not attaching raw logs, full JSONL files, auth files, database files, or unrelated prompt content because they may contain sensitive local context.