Windows Desktop: bundled node_repl MCP processes leak one-per-thread, never reaped until app-server exit

[mingisrookie]

What version of Codex is running?

• Codex Desktop 26.721.4979.0 (native Windows, no WSL)
• app-server: codex-cli 0.146.0-alpha.3.1
• Bundled runtime: cua_node/f8d2abcb7481383b

What operating system are you using?

Windows 11 x64, 24 GB RAM.

What is the issue?

node_repl.exe MCP server child processes accumulate over the life of the codex.exe app-server process and are never reaped. One new node_repl.exe appears roughly per opened conversation/thread, stays alive after the thread is idle or closed, and only goes away when the app-server itself exits.

Snapshot after ~8 hours of normal Desktop usage — 14 live node_repl.exe, all children of the single app-server PID, all idle (0 CPU since spawn):

ProcessId CreationDate            Parent
17248     12:41  (app start)      codex.exe (1772)
16888     13:12                   codex.exe (1772)
19040     13:43                   codex.exe (1772)
 5508     15:18                   codex.exe (1772)
21312     18:40                   codex.exe (1772)
 1668     19:02                   codex.exe (1772)
21144     19:47                   codex.exe (1772)
 9004     19:58                   codex.exe (1772)
20704     19:58                   codex.exe (1772)
21984     20:04                   codex.exe (1772)
20664     20:12                   codex.exe (1772)
14232     20:18                   codex.exe (1772)
20508     20:18                   codex.exe (1772)
20588     20:19                   codex.exe (1772)

Each holds ~7–9 MB working set and ~115–125 handles. Individually small, but they accumulate monotonically (verified creation timestamps map to thread-open events) and add up alongside the other per-thread state. Killing the app-server reaps all of them (verified: after terminating the app-server PID, node_repl.exe count went from 14 to 0).

Relevant config: [mcp_servers.node_repl] pointing at the bundled node_repl.exe, features.computer_use = true, features.multi_agent = true.

What is the expected behavior?

node_repl MCP processes for a thread should be terminated when the thread is closed/idle-expired, or at minimum pooled/reused, instead of leaking one process per thread until app exit.

Additional context

Possibly related to #30408 (per-thread MCP server processes never cleaned up), but this one is specifically the bundled node_repl on native Windows, where each thread spawns a distinct child that outlives the thread.

[github-actions]

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

• Windows native 26.715: chat resume launches retained MCP stacks, including disabled/unlisted plugins #34251
• Codex app-server retains stdio MCP process pairs after task/thread teardown on 0.145.0-alpha.18 #34410
• [Windows 26.715] app-server retains repeated full stdio MCP batches, consuming 10.6 GB private memory #34704
• Windows 26.715: duplicate MCP suites accumulate per session; termination misses cmd.exe/node.exe grandchildren (Job Object pattern exists in-repo but unused on MCP spawn path) #34614

Powered by Codex Action

[misosiruda]

Current Windows reproduction and lifecycle analysis

Update: I initially scoped the likely cause too narrowly to subscribed-thread retention. After reviewing prior unmerged work, current main still has at least one additional plausible lifecycle-retention path around detached MCP status/resource/tool RPC work. The analysis and proposed order below now include that prior art.

I reproduced the same process-retention pattern on a newer Windows Desktop build:

• Codex Desktop: 26.730.7989.0
• bundled app-server: codex-cli 0.147.0-alpha.1.2
• Windows 11 x64
• root Desktop app-server uptime at the latest capture: about 3h48m

At an earlier point in the same app-server lifetime I observed 7 direct node_repl.exe children using about 143.5 MiB combined. A fresh read-only capture at 2026-08-05T13:56+09:00 showed 4 direct children using 81.3 MiB and 532 handles. Three of the four used at most 0.02 CPU seconds during a three-second sample; one was active and owned a nested stdio app-server.

This is an important distinction: these are not Windows PPID-orphans. They remain direct children of the live Desktop app-server (and were inside its Job in the earlier snapshot). Also, my count did decrease from 7 to 4 during the investigation, so my reproduction supports long-lived/logically retained runtimes, but does not support claiming that every instance is literally never reaped under every lifecycle path. Process inspection alone also cannot attribute every retained node_repl.exe to a particular thread, status snapshot, hidden task, or other runtime owner.

Relevant current-main behavior

I traced current main at 5d89ab65dc9d4d0c55796c11df112b54157922b4.

The per-thread path behaves as follows:

• The app-server unload delay is fixed at 30 minutes, and an unload target exists only when the thread is both inactive and has no subscribers:
  

  codex/codex-rs/app-server/src/request_processors/thread_lifecycle.rs

  Lines 5 to 62 in 5d89ab6

  	pub(super) const THREAD_UNLOADING_DELAY: Duration = Duration::from_secs(30 * 60);
  	#[derive(Clone)]
  	pub(super) struct ListenerTaskContext {
  	pub(super) thread_manager: Arc<ThreadManager>,
  	pub(super) thread_state_manager: ThreadStateManager,
  	pub(super) outgoing: Arc<OutgoingMessageSender>,
  	pub(super) pending_thread_unloads: Arc<Mutex<HashSet<ThreadId>>>,
  	pub(super) thread_watch_manager: ThreadWatchManager,
  	pub(super) thread_list_state_permit: Arc<Semaphore>,
  	pub(super) fallback_model_provider: String,
  	pub(super) codex_home: PathBuf,
  	pub(super) skills_watcher: Arc<SkillsWatcher>,
  	}
  	struct UnloadingState {
  	delay: Duration,
  	has_subscribers_rx: watch::Receiver<bool>,
  	has_subscribers: (bool, Instant),
  	thread_status_rx: watch::Receiver<ThreadStatus>,
  	is_active: (bool, Instant),
  	}
  	impl UnloadingState {
  	async fn new(
  	listener_task_context: &ListenerTaskContext,
  	thread_id: ThreadId,
  	delay: Duration,
  	) -> Option<Self> {
  	let has_subscribers_rx = listener_task_context
  	.thread_state_manager
  	.subscribe_to_has_connections(thread_id)
  	.await?;
  	let thread_status_rx = listener_task_context
  	.thread_watch_manager
  	.subscribe(thread_id)
  	.await?;
  	let has_subscribers = (*has_subscribers_rx.borrow(), Instant::now());
  	let is_active = (
  	matches!(*thread_status_rx.borrow(), ThreadStatus::Active { .. }),
  	Instant::now(),
  	);
  	Some(Self {
  	delay,
  	has_subscribers_rx,
  	has_subscribers,
  	thread_status_rx,
  	is_active,
  	})
  	}
  	fn unloading_target(&self) -> Option<Instant> {
  	match (self.has_subscribers, self.is_active) {
  	((false, has_no_subscribers_since), (false, is_inactive_since)) => {
  	Some(std::cmp::max(has_no_subscribers_since, is_inactive_since) + self.delay)
  	}
  	_ => None,
  	}

• thread/unsubscribe removes the connection subscription but does not immediately shut down the thread:
  

  codex/codex-rs/app-server/src/request_processors/thread_processor.rs

  Lines 887 to 912 in 5d89ab6

  	async fn thread_unsubscribe_response_inner(
  	&self,
  	params: ThreadUnsubscribeParams,
  	connection_id: ConnectionId,
  	) -> Result<ThreadUnsubscribeResponse, JSONRPCErrorError> {
  	let thread_id = ThreadId::from_string(&params.thread_id)
  	.map_err(|err| invalid_request(format!("invalid thread id: {err}")))?;
  	if self.thread_manager.get_thread(thread_id).await.is_err() {
  	self.finalize_thread_teardown(thread_id).await;
  	return Ok(ThreadUnsubscribeResponse {
  	status: ThreadUnsubscribeStatus::NotLoaded,
  	});
  	};
  	let was_subscribed = self
  	.thread_state_manager
  	.unsubscribe_connection_from_thread(thread_id, connection_id)
  	.await;
  	let status = if was_subscribed {
  	ThreadUnsubscribeStatus::Unsubscribed
  	} else {
  	ThreadUnsubscribeStatus::NotSubscribed
  	};
  	Ok(ThreadUnsubscribeResponse { status })

• Once thread shutdown is actually entered, it calls mcp_runtime.shutdown():
  

  codex/codex-rs/core/src/session/handlers.rs

  Lines 587 to 609 in 5d89ab6

  	async fn shutdown_session_runtime(sess: &Arc<Session>) {
  	if let Some(startup_prewarm) = sess.take_session_startup_prewarm().await {
  	startup_prewarm.abort().await;
  	}
  	let _ = sess.conversation.shutdown().await;
  	sess.abort_all_tasks(TurnAbortReason::Interrupted).await;
  	sess.services
  	.unified_exec_manager
  	.terminate_all_processes()
  	.await;
  	if let Err(err) = sess.services.code_mode_service.shutdown().await {
  	warn!("failed to shutdown code mode session: {err}");
  	}
  	sess.stop_mcp_prewarm_worker().await;
  	{
  	let _refresh = sess.mcp_refresh.acquire().await;
  	sess.mcp_refresh.close();
  	sess.services.mcp_runtime.shutdown().await;
  	}
  	sess.guardian_review_session.shutdown().await;
  	crate::hook_runtime::run_session_end_hooks(sess).await;
  	}

There is also a separate RPC/temporary-manager path that should not be conflated with thread subscription retention:

• Current app-server code still detaches mcpServerStatus/list, resource reads, and tool calls with tokio::spawn:
  

  codex/codex-rs/app-server/src/request_processors/mcp_processor.rs

  Lines 234 to 305 in 5d89ab6

  	async fn list_mcp_server_status(
  	&self,
  	request_id: &ConnectionRequestId,
  	params: ListMcpServerStatusParams,
  	) -> Result<(), JSONRPCErrorError> {
  	let request = request_id.clone();
  	let outgoing = Arc::clone(&self.outgoing);
  	let (config, thread) = match params.thread_id.as_deref() {
  	Some(thread_id) => {
  	let (_, thread) = self.load_thread(thread_id).await?;
  	let thread_config = thread.config().await;
  	let config = self
  	.config_manager
  	.load_latest_config_for_thread(thread_config.as_ref())
  	.await
  	.map_err(|err| internal_error(format!("failed to reload config: {err}")))?;
  	(config, Some(thread))
  	}
  	None => (self.load_latest_config(/*fallback_cwd*/ None).await?, None),
  	};
  	let mcp_manager = self.thread_manager.mcp_manager();
  	let auth = self.auth_manager.auth().await;
  	let (mcp_config, runtime_context) = match thread {
  	Some(thread) => thread.runtime_mcp_config_and_context(&config).await,
  	None => {
  	let mcp_config = mcp_manager.runtime_config(&config).await;
  	let runtime_context = McpRuntimeContext::new(
  	self.thread_manager.environment_manager(),
  	config.cwd.to_path_buf(),
  	);
  	(mcp_config, runtime_context)
  	}
  	};
  	tokio::spawn(async move {
  	Self::list_mcp_server_status_task(
  	outgoing,
  	request,
  	params,
  	mcp_config,
  	auth,
  	runtime_context,
  	mcp_manager,
  	)
  	.await;
  	});
  	Ok(())
  	}
  	async fn list_mcp_server_status_task(
  	outgoing: Arc<OutgoingMessageSender>,
  	request_id: ConnectionRequestId,
  	params: ListMcpServerStatusParams,
  	mcp_config: codex_mcp::McpConfig,
  	auth: Option<CodexAuth>,
  	runtime_context: McpRuntimeContext,
  	mcp_manager: Arc<McpManager>,
  	) {
  	let result = Self::list_mcp_server_status_response(
  	request_id.request_id.to_string(),
  	params,
  	mcp_config,
  	auth,
  	runtime_context,
  	mcp_manager,
  	)
  	.await;
  	outgoing.send_result(request_id, result).await;
  	}
  	async fn list_mcp_server_status_response(

  
  

  codex/codex-rs/app-server/src/request_processors/mcp_processor.rs

  Lines 391 to 480 in 5d89ab6

  	async fn read_mcp_resource(
  	&self,
  	request_id: &ConnectionRequestId,
  	params: McpResourceReadParams,
  	) -> Result<(), JSONRPCErrorError> {
  	let outgoing = Arc::clone(&self.outgoing);
  	let McpResourceReadParams {
  	thread_id,
  	server,
  	uri,
  	} = params;
  	if let Some(thread_id) = thread_id {
  	let (_, thread) = self.load_thread(&thread_id).await?;
  	let request_id = request_id.clone();
  	tokio::spawn(async move {
  	let result = thread.read_mcp_resource(&server, &uri).await;
  	Self::send_mcp_resource_read_response(outgoing, request_id, result).await;
  	});
  	return Ok(());
  	}
  	let config = self.load_latest_config(/*fallback_cwd*/ None).await?;
  	let mcp_manager = self.thread_manager.mcp_manager();
  	let mcp_config = mcp_manager.runtime_config(&config).await;
  	let codex_apps_tools_cache = mcp_manager.codex_apps_tools_cache();
  	let tool_catalog_cache = mcp_manager.tool_catalog_cache();
  	let auth = self.auth_manager.auth().await;
  	let environment_manager = self.thread_manager.environment_manager();
  	// This threadless resource-read path has no turn cwd or turn-selected
  	// environment. Use config cwd only as the local stdio fallback; named
  	// environment stdio MCPs must declare their own absolute cwd.
  	let runtime_context =
  	McpRuntimeContext::new(Arc::clone(&environment_manager), config.cwd.to_path_buf());
  	let request_id = request_id.clone();
  	tokio::spawn(async move {
  	let result = read_mcp_resource_without_thread(
  	&mcp_config,
  	auth.as_ref(),
  	runtime_context,
  	codex_apps_tools_cache,
  	tool_catalog_cache,
  	&server,
  	&uri,
  	)
  	.await
  	.and_then(|result| serde_json::to_value(result).map_err(anyhow::Error::from));
  	Self::send_mcp_resource_read_response(outgoing, request_id, result).await;
  	});
  	Ok(())
  	}
  	async fn send_mcp_resource_read_response(
  	outgoing: Arc<OutgoingMessageSender>,
  	request_id: ConnectionRequestId,
  	result: anyhow::Result<serde_json::Value>,
  	) {
  	let result = result
  	.map_err(|error| internal_error(format!("{error:#}")))
  	.and_then(|result| {
  	serde_json::from_value::<McpResourceReadResponse>(result).map_err(|error| {
  	internal_error(format!(
  	"failed to deserialize MCP resource read response: {error}"
  	))
  	})
  	});
  	outgoing.send_result(request_id, result).await;
  	}
  	async fn call_mcp_server_tool(
  	&self,
  	request_id: &ConnectionRequestId,
  	params: McpServerToolCallParams,
  	) -> Result<(), JSONRPCErrorError> {
  	let outgoing = Arc::clone(&self.outgoing);
  	let thread_id = params.thread_id.clone();
  	let (_, thread) = self.load_thread(&thread_id).await?;
  	let meta = with_mcp_tool_call_thread_id_meta(params.meta, &thread_id);
  	let request_id = request_id.clone();
  	tokio::spawn(async move {
  	let result = thread
  	.call_mcp_tool(&params.server, &params.tool, params.arguments, meta)
  	.await
  	.map(McpServerToolCallResponse::from)
  	.map_err(|error| internal_error(format!("{error:#}")));
  	outgoing.send_result(request_id, result).await;
  	});

• The threadless status snapshot creates a fresh McpConnectionSet, then cancels its startup token and returns without explicitly awaiting shutdown():
  

  codex/codex-rs/codex-mcp/src/mcp/mod.rs

  Lines 393 to 451 in 5d89ab6

  	pub async fn collect_mcp_server_status_snapshot_with_detail(
  	config: &McpConfig,
  	auth: Option<&CodexAuth>,
  	submit_id: String,
  	runtime_context: McpRuntimeContext,
  	codex_apps_tools_cache: ConnectorRuntimeManager<ToolInfo>,
  	tool_catalog_cache: crate::McpToolCatalogCache,
  	detail: McpSnapshotDetail,
  	) -> McpServerStatusSnapshot {
  	let mcp_servers = effective_mcp_servers(config, auth);
  	if mcp_servers.is_empty() {
  	return McpServerStatusSnapshot {
  	server_infos: HashMap::new(),
  	tools_by_server: HashMap::new(),
  	resources: HashMap::new(),
  	resource_templates: HashMap::new(),
  	auth_statuses: HashMap::new(),
  	server_names: Vec::new(),
  	};
  	}
  	let auth_status_entries = compute_auth_statuses(
  	mcp_servers.iter(),
  	config.mcp_oauth_credentials_store_mode,
  	config.auth_keyring_backend_kind,
  	auth,
  	&runtime_context,
  	)
  	.await;
  	let server_names = mcp_servers.keys().cloned().collect();
  	let cancel_token = CancellationToken::new();
  	let mut runtime_config = config.clone();
  	runtime_config.permission_profile = PermissionProfile::default();
  	let mcp_connection_manager = McpConnectionSet::new(
  	/*previous*/ None,
  	McpPublicationGate::already_published(),
  	McpRuntimeInput {
  	config: Arc::new(runtime_config),
  	plugins_available: false,
  	ready_selected_capability_roots: Vec::new(),
  	mcp_servers,
  	submit_id,
  	tx_event: None,
  	startup_cancellation_token: cancel_token.clone(),
  	runtime_context,
  	codex_apps_tools_cache,
  	tool_catalog_cache,
  	codex_apps_tools_cache_key: connector_runtime_context_key(auth),
  	client_mcp_extensions: ClientMcpExtensions::default(),
  	auth: auth.cloned(),
  	codex_apps_auth_manager: None,
  	elicitation_reviewer: None,
  	elicitation_lifecycle: None,
  	},
  	crate::elicitation::ElicitationRequestRouter::default(),
  	)
  	.await;

• The Windows local-stdio terminator uses taskkill /PID ... /T /F, but current code discards the command status:
  

  codex/codex-rs/rmcp-client/src/stdio_server_launcher.rs

  Lines 373 to 386 in 5d89ab6

  	});
  	}
  	}
  	#[cfg(windows)]
  	fn terminate(&self) {
  	let _ = std::process::Command::new("taskkill")
  	.arg("/PID")
  	.arg(self.pid.to_string())
  	.arg("/T")
  	.arg("/F")
  	.stdin(Stdio::null())
  	.stdout(Stdio::null())
  	.stderr(Stdio::null())

The evidence therefore points to at least two plausible retention mechanisms:

1. loaded per-thread MCP runtimes that never become eligible for the no-subscriber idle-unload path because Desktop keeps background/sidebar threads subscribed;
2. temporary or thread-associated MCP work whose detached RPC task outlives the serialized request lifecycle or is not explicitly drained.

The first mechanism is consistent with the controlled subscribed-thread analysis reported in #20883:
#20883 (comment)

Relevant prior work that was not merged

Three earlier PRs overlap materially with this issue and should be evaluated before designing a new fix:

• Fix MCP status/list lifecycle leak #20447, “Fix MCP status/list lifecycle leak”, awaited status/resource/tool work inside the request future, explicitly shut down temporary managers, surfaced Windows taskkill failures, and added serialization coverage. It was closed as stale without being merged:
  Fix MCP status/list lifecycle leak #20447
• [app-server] Reap orphaned idle threads on websocket disconnect #14997, “Reap orphaned idle threads on websocket disconnect”, immediately unloaded an inactive persisted thread after its final websocket disconnected and included a real stdio-helper before/after regression. It was also closed as stale without being merged:
  [app-server] Reap orphaned idle threads on websocket disconnect #14997
• [MCP caching]: pool MCP backends in thread manager #15258, “pool MCP backends in thread manager”, explored sharing local stdio MCP backends across loaded threads and added unsubscribe/archive/resume lifecycle coverage. It was closed without being merged:
  [MCP caching]: pool MCP backends in thread manager #15258

These PRs target different layers, so none should be assumed to be a complete standalone fix for the current architecture. In particular, #20447 addresses detached temporary-manager/RPC lifetime, while #14997 and #15258 address per-thread retention and duplication.

Proposed fix direction

My preferred order would now be:

1. Re-evaluate and port the narrow intent of Fix MCP status/list lifecycle leak #20447 onto current mcp_processor.rs:
   • keep serialized MCP RPC work inside the tracked request future where possible;
   • explicitly drain temporary MCP connection sets;
   • surface failed Windows process-tree termination;
   • add a regression that distinguishes thread-owned runtimes from temporary status/resource runtimes.
2. Fix the loaded-thread ownership path:
   • have Desktop unsubscribe from background threads when it no longer needs live turn/item events;
   • consider an explicitly negotiated or initially opt-in app-server subscribed-idle safety valve;
   • never evict an active turn/agent or a thread with pending server requests;
   • reset the timer on real thread activity;
   • use the existing shutdown path, emit thread/closed, and preserve resume from the persisted rollout.
3. Treat project/app-server-scoped MCP pooling as a separate, larger design decision after the two cleanup paths above are bounded.

Regression coverage should include:

• serialized status/resource/tool requests do not leave temporary MCP processes behind;
• subscribed idle eviction;
• active-turn protection;
• activity resetting the deadline;
• resume after eviction;
• actual stdio MCP child-tree exit on Windows.

The last item is currently a coverage gap: the existing real-process cleanup integration test is Unix-only:

codex/codex-rs/rmcp-client/tests/process_group_cleanup.rs

Lines 1 to 119 in 5d89ab6

	#![cfg(unix)]
	use std::collections::HashMap;
	use std::ffi::OsString;
	use std::fs;
	use std::path::Path;
	use std::sync::Arc;
	use std::time::Duration;
	use anyhow::Context;
	use anyhow::Result;
	use codex_rmcp_client::ElicitationAction;
	use codex_rmcp_client::ElicitationResponse;
	use codex_rmcp_client::LocalStdioServerLauncher;
	use codex_rmcp_client::RmcpClient;
	use futures::FutureExt as _;
	use rmcp::model::ClientCapabilities;
	use rmcp::model::Implementation;
	use rmcp::model::InitializeRequestParams;
	use rmcp::model::ProtocolVersion;
	use serde_json::json;
	fn stdio_server_bin() -> Result<std::path::PathBuf> {
	codex_utils_cargo_bin::cargo_bin("test_stdio_server").map_err(Into::into)
	}
	fn init_params() -> InitializeRequestParams {
	InitializeRequestParams::new(
	ClientCapabilities::default(),
	Implementation::new("codex-test", "0.0.0-test").with_title("Codex rmcp shutdown test"),
	)
	.with_protocol_version(ProtocolVersion::V_2025_06_18)
	}
	fn process_exists(pid: u32) -> bool {
	std::process::Command::new("kill")
	.arg("-0")
	.arg(pid.to_string())
	.stderr(std::process::Stdio::null())
	.status()
	.map(|status| status.success())
	.unwrap_or(false)
	}
	async fn wait_for_pid_file(path: &Path) -> Result<u32> {
	for _ in 0..50 {
	match fs::read_to_string(path) {
	Ok(content) => {
	let trimmed = content.trim();
	if trimmed.is_empty() {
	tokio::time::sleep(Duration::from_millis(100)).await;
	continue;
	}
	let pid = trimmed
	.parse::<u32>()
	.with_context(|| format!("failed to parse pid from {}", path.display()))?;
	return Ok(pid);
	}
	Err(error) if error.kind() == std::io::ErrorKind::NotFound => {
	tokio::time::sleep(Duration::from_millis(100)).await;
	}
	Err(error) => {
	return Err(error).with_context(|| format!("failed to read {}", path.display()));
	}
	}
	}
	anyhow::bail!("timed out waiting for child pid file at {}", path.display());
	}
	async fn wait_for_process_exit(pid: u32) -> Result<()> {
	for _ in 0..50 {
	if !process_exists(pid) {
	return Ok(());
	}
	tokio::time::sleep(Duration::from_millis(100)).await;
	}
	anyhow::bail!("process {pid} still running after timeout");
	}
	#[tokio::test(flavor = "multi_thread", worker_threads = 1)]
	async fn drop_kills_wrapper_process_group() -> Result<()> {
	let temp_dir = tempfile::tempdir()?;
	let child_pid_file = temp_dir.path().join("child.pid");
	let child_pid_file_str = child_pid_file.to_string_lossy().into_owned();
	let client = RmcpClient::new_stdio_client(
	OsString::from("/bin/sh"),
	vec![
	OsString::from("-c"),
	OsString::from(
	"sleep 300 & child_pid=$!; echo \"$child_pid\" > \"$CHILD_PID_FILE\"; cat >/dev/null",
	),
	],
	Some(HashMap::from([(
	OsString::from("CHILD_PID_FILE"),
	OsString::from(child_pid_file_str),
	)])),
	&[],
	/*cwd*/ None,
	Arc::new(LocalStdioServerLauncher::new(std::env::current_dir()?)),
	)
	.await?;
	let grandchild_pid = wait_for_pid_file(&child_pid_file).await?;
	assert!(
	process_exists(grandchild_pid),
	"expected grandchild process {grandchild_pid} to be running before dropping client"
	);
	drop(client);
	wait_for_process_exit(grandchild_pid).await
	}
	#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
	async fn shutdown_kills_initialized_stdio_server_with_in_flight_operation() -> Result<()> {

Would maintainers prefer reviving the narrow #20447 lifecycle fix first, a Desktop subscription fix, or a combined staged approach? If one of those directions aligns with the intended lifecycle, I would be happy to prepare a small, test-first PR if invited.