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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   remote

   automations

   on May 23, 2026
2. github-actions commented on May 23, 2026

   

   github-actionsbot

   on May 23, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Remote mobile-started and CLI-started threads are not listed in the mobile app for resume #23351

   Powered by Codex Action
3. ax-openai commented on May 28, 2026

   

   ax-openai

   on May 28, 2026

   More actions

   Thanks for all the details. I'm looking into remote automations. I'll keep you posted here!

   ❤️React with ❤️2Reacted by David Franklin and Alessandro
4. ax-openai

   self-assigned this

   on May 29, 2026
5. jmabry commented on Jun 4, 2026

   

   jmabry

   on Jun 4, 2026

   More actions

   Confirmed I'm seeing the same bug
6. davidwiet commented on Aug 3, 2026

   

   davidwiet

   on Aug 3, 2026

   More actions

   Still reproducible on 2026-08-03 with Codex Desktop release 26.727.40816 / embedded CLI 0.146.0-alpha.9.2.

   New affected Remote-created thread: 019fc5db-9e4d-7892-b5b1-e697cd7792c5. Its initial session_meta has neither thread_source nor dynamic_tools. Comparable locally initiated root threads on the same build have thread_source: "user" and the codex_app bundle containing automation_update; an automation-started thread has thread_source: "automation" and the bundle as well.

   At the affected thread creation time (2026-08-03T04:22:12Z), Desktop logs begin with browser/session route capture and contain no local thread/start -> Conversation created -> plugin/list sequence. A same-build locally initiated thread shows that complete sequence. Continuing the affected thread locally and switching models does not re-provision the missing tool bundle.

   Fresh diagnostics were uploaded through /feedback: 019fc658-2f6e-77e0-8cec-5a4382b2b2b5. The feedback description identifies the affected thread above and the prior working automation thread 019f66c5-c39c-7582-81fb-7fba477f3dbe.
7. TheLoroXD commented on Aug 12, 2026

   

   TheLoroXD

   on Aug 12, 2026

   More actions

   Independent Linux + iOS Remote reproduction and no-UI workaround

   I reproduced this on 2026-08-12 with a Linux Desktop host:

   • ChatGPT/Codex Desktop RPM: 26.803.81509-1
   • Bundled Codex: 0.147.0-alpha.6.6
   • Host OS: Fedora Linux 43 container image, x86_64
   • Initiating client: ChatGPT iOS Remote
   • Execution target: a saved local Git project on the same Linux Desktop host

   Reproduction

   1. From iOS Remote, create a new Codex thread targeting a project on the connected Linux Desktop host.
   2. Continue the same thread later from Codex Desktop on that host.
   3. Ask the thread to create a same-thread heartbeat, or inspect its initial session_meta.dynamic_tools.

   The remote-created thread had normal local shell/project access and these host thread-management tools:

   create_thread
   fork_thread
   list_projects
   list_threads
   navigate_to_codex_page
   read_thread
   send_message_to_thread
   set_thread_archived
   set_thread_pinned
   set_thread_title
   

   However, automation_update was absent. Opening/resuming the thread directly in Desktop did not add it. The Desktop Scheduled UI could still create schedules, and a fresh local control thread on the same app/account/host did receive automation_update.

   This rules out Linux support, app version, account entitlement, and the host automation subsystem. The capability difference is tied to the thread creation route and remains sticky after resume.

   Additional project-routing inconsistency

   The affected remote-created thread could call both list_projects and create_thread, but:

   1. list_projects returned the saved Linux project as schema v2 with projectKind: local, hostId: local, and a UUID projectId.
   2. Passing that exact ID immediately to create_thread with environment: {type: "local"} failed with:

   Unknown projectId: <same UUID>. Call list_projects to find available projects.
   

   This overlaps #37630, although that report uses Realtime Voice/macOS while this reproduction is iOS Remote/Linux.

   Confirmed workaround without manually editing automation state

   A two-step local bootstrap worked:

   1. From the affected remote-created thread, call create_thread with a projectless target and carry the original request plus essential context into its prompt.
   2. That new thread is created with hostId: local; its initial session_meta.dynamic_tools includes automation_update.
   3. From the local bootstrap thread, call list_projects and then create_thread for the desired saved project with environment: {type: "local"}.
   4. The resulting project thread has the correct project cwd, remains hostId: local, and also includes automation_update.
   5. Continue the task from that project thread. It can create the heartbeat normally.

   Starting the project thread manually in Desktop and then continuing it from iOS also works, as already described in this issue.

   As a temporary guardrail, I added a global ~/.codex/AGENTS.md instruction that checks for automation_update on the first turn. If it is absent, the agent warns that the thread was probably initiated remotely and offers either to continue without agent-managed automations or create a fresh local thread carrying the request/context. This does not fix capability provisioning; it only prevents users from discovering the limitation halfway through a long-running task.

   Source-level observation

   Current main models dynamic tools as creation-time input:

   • ThreadStartParams.dynamic_tools:

     codex/codex-rs/app-server-protocol/src/protocol/v2/thread.rs

     Lines 129 to 135 in 130c7c9

     	#[experimental("thread/start.dynamicTools")]
     	#[serde(
     	default,
     	deserialize_with = "codex_protocol::dynamic_tools::deserialize_dynamic_tool_specs"
     	)]
     	#[ts(optional = nullable)]
     	pub dynamic_tools: Option<Vec<DynamicToolSpec>>,

   • ThreadResumeParams has no corresponding dynamic-tools refresh input:

     codex/codex-rs/app-server-protocol/src/protocol/v2/thread.rs

     Lines 326 to 389 in 130c7c9

     	pub struct ThreadResumeParams {
     	pub thread_id: String,
     	/// [UNSTABLE] FOR CODEX CLOUD - DO NOT USE.
     	/// If specified, the thread will be resumed with the provided history
     	/// instead of loaded from disk.
     	#[experimental("thread/resume.history")]
     	#[ts(optional = nullable)]
     	pub history: Option<Vec<ResponseItem>>,
     	/// [UNSTABLE] Specify the rollout path to resume from.
     	/// If specified for a non-running thread, the thread_id param will be ignored.
     	/// If thread_id identifies a running thread, the path must match the active
     	/// rollout path.
     	#[experimental("thread/resume.path")]
     	#[serde(
     	default,
     	deserialize_with = "crate::protocol::serde_helpers::deserialize_empty_path_as_none"
     	)]
     	#[ts(optional = nullable)]
     	pub path: Option<PathBuf>,
     	/// Configuration overrides for the resumed thread, if any.
     	#[ts(optional = nullable)]
     	pub model: Option<String>,
     	#[ts(optional = nullable)]
     	pub model_provider: Option<String>,
     	#[serde(
     	default,
     	deserialize_with = "crate::protocol::serde_helpers::deserialize_double_option",
     	serialize_with = "crate::protocol::serde_helpers::serialize_double_option",
     	skip_serializing_if = "Option::is_none"
     	)]
     	#[ts(optional = nullable)]
     	pub service_tier: Option<Option<String>>,
     	#[ts(optional = nullable)]
     	pub cwd: Option<String>,
     	/// Replace the thread's runtime workspace roots. Paths must be absolute.
     	#[experimental("thread/resume.runtimeWorkspaceRoots")]
     	#[ts(optional = nullable)]
     	pub runtime_workspace_roots: Option<Vec<AbsolutePathBuf>>,
     	#[experimental(nested)]
     	#[ts(optional = nullable)]
     	pub approval_policy: Option<AskForApproval>,
     	/// Override where approval requests are routed for review on this thread
     	/// and subsequent turns.
     	#[ts(optional = nullable)]
     	pub approvals_reviewer: Option<ApprovalsReviewer>,
     	#[ts(optional = nullable)]
     	pub sandbox: Option<SandboxMode>,
     	/// Named profile id for the resumed thread. Cannot be combined with
     	/// `sandbox`.
     	#[experimental("thread/resume.permissions")]
     	#[ts(optional = nullable)]
     	pub permissions: Option<String>,
     	#[ts(optional = nullable)]
     	pub config: Option<HashMap<String, serde_json::Value>>,
     	#[ts(optional = nullable)]
     	pub base_instructions: Option<String>,
     	#[ts(optional = nullable)]
     	pub developer_instructions: Option<String>,
     	#[ts(optional = nullable)]
     	pub personality: Option<Personality>,
     	/// When true, return only thread metadata and live-resume state without

   • Core regression coverage explicitly verifies that resume restores dynamic tools from the rollout:

     codex/codex-rs/core/tests/suite/sqlite_state.rs

     Lines 112 to 190 in 130c7c9

     	#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
     	async fn resume_restores_dynamic_tools_from_rollout_with_sqlite_enabled() -> Result<()> {
     	let server = start_mock_server().await;
     	let mock = mount_sse_sequence(
     	&server,
     	vec![
     	responses::sse(vec![ev_response_created("resp-1"), ev_completed("resp-1")]),
     	responses::sse(vec![ev_response_created("resp-2"), ev_completed("resp-2")]),
     	],
     	)
     	.await;
     	let namespace = "resume_tools";
     	let namespace_description = "Tools available after resume.";
     	let tool_name = "resume_lookup";
     	let tool_description = "Look up a value after resume.";
     	let input_schema = json!({
     	"type": "object",
     	"properties": { "query": { "type": "string" } },
     	"required": ["query"],
     	"additionalProperties": false,
     	});
     	let dynamic_tool = DynamicToolSpec::Namespace(DynamicToolNamespaceSpec {
     	name: namespace.to_string(),
     	description: namespace_description.to_string(),
     	tools: vec![DynamicToolNamespaceTool::Function(
     	DynamicToolFunctionSpec {
     	name: tool_name.to_string(),
     	description: tool_description.to_string(),
     	input_schema: input_schema.clone(),
     	defer_loading: false,
     	},
     	)],
     	});
     	let mut builder = test_codex().with_config(|config| {
     	config
     	.features
     	.enable(Feature::Sqlite)
     	.expect("test config should allow feature update");
     	});
     	let base_test = builder.build(&server).await?;
     	let started = base_test
     	.thread_manager
     	.start_thread(StartThreadOptions {
     	dynamic_tools: vec![dynamic_tool],
     	..StartThreadOptions::new(base_test.config.clone())
     	})
     	.await?;
     	let rollout_path = started
     	.session_configured
     	.rollout_path
     	.clone()
     	.expect("rollout path");
     	started
     	.thread
     	.submit(Op::UserInput {
     	items: vec![UserInput::Text {
     	text: "persist this thread".to_string(),
     	text_elements: Vec::new(),
     	}],
     	final_output_json_schema: None,
     	responsesapi_client_metadata: None,
     	additional_context: Default::default(),
     	thread_settings: Default::default(),
     	})
     	.await?;
     	wait_for_event(&started.thread, |event| {
     	matches!(event, EventMsg::TurnComplete(_))
     	})
     	.await;
     	started.thread.shutdown_and_wait().await?;
     	let mut resume_builder = test_codex().with_config(|config| {
     	config
     	.features
     	.enable(Feature::Sqlite)
     	.expect("test config should allow feature update");
     	});

   That matches the observed behavior: a reduced tool set selected during remote thread/start is persisted, and later Desktop resume cannot repair it.

   Expected behavior

   A thread created remotely on a connected local host should receive the safe host-owned tools available to an equivalent locally-created thread. If that is intentionally restricted, the app should surface the limitation before starting work and offer a first-class Continue in a new local thread with current tools action that preserves the request and essential context.

   Related: #31613 for the iOS-specific symptom and #37630 for the list_projects/create_thread ID mismatch.