Repository navigation
Regression: headless SSH tasks lose thread messaging and delegation tools after Desktop update #42973
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.901.31953 (build 7868); remote Codex CLI/app-server 0.153.4
What subscription do you have?
ChatGPT Pro 5x
What platform is your computer?
Desktop client: macOS. Remote execution host: headless Linux HPC node connected through SSH, running Codex CLI/app-server without the Codex desktop app.
What issue are you seeing?
Headless SSH tasks have lost send_message_to_thread, create_thread, fork_thread, and handoff_thread from their live tool catalog. list_threads still works. This workflow worked approximately one week ago and stopped working after a recent Codex update; I do not have the exact last working build.
Tasks on other computers that run the Codex app still have thread messaging when I connect to them. The affected case is specifically the headless SSH host.
Impact: Remote SSH threads cannot communicate or coordinate with each other. A remote thread acting as a coordinator cannot message another remote thread, and remote threads cannot exchange instructions, progress updates, or completion reports through send_message_to_thread. This affects coordination entirely among remote threads, as well as callbacks from remote workers to a local coordinator.
Using a local coordinator to wait or poll for completion only partially works around this: it does not restore direct remote-to-remote communication or allow remote threads to coordinate independently.
The operations are absent, rather than failing with a tool-call error. A fresh task reproduces this.
What steps can reproduce the bug?
Feedback ID: 01a070ce-3f7b-7181-8b37-7dd2bf6eaab7
- Connect Codex Desktop to a headless Linux host over SSH running Codex CLI/app-server 0.153.4.
- Open two tasks on the remote SSH host.
- Ask one remote task to message the other using send_message_to_thread, for example to coordinate work or share a status update.
- Observe that send_message_to_thread is absent from the calling remote task’s live tool catalog. The other remote task also lacks it, so neither can initiate messaging to the other.
- list_threads remains available, while create_thread, fork_thread, and handoff_thread are also absent.
- Compare with a local Desktop task, where these operations are exposed.
What is the expected behavior?
Headless SSH tasks should retain cross-task messaging and delegation support, as they did approximately one week ago. Remote threads should be able to call send_message_to_thread to coordinate directly with other remote threads, exchange instructions and status, and report completion or requests for attention to either a remote or local coordinator.
Please restore support through the SSH integration, or provide a supported codex_app MCP bridge for headless hosts.
Additional information
Read-only diagnosis of the installed Desktop bundle found a concrete exclusion path:
- In webview/assets/app-initial-caa927532ffb.js, pPi.readInputs() assigns usesDesktopMcp = ik(hostId).
- ik() requires the host to match the renderer host_config.id and have kind === "local"; its fallback checks hostId === "local". The SSH host does not qualify.
- Local tasks use the codex_app MCP server and supply tool names through mcp_servers.codex_app.enabled_tools.
- The alternative dynamic-tool path calls OOt(), whose AOt exclusion set contains automation_update, create_thread, send_message_to_thread, fork_thread, and handoff_thread.
- GSa() also rejects these operations at execution time through the dynamic route with: "This app tool is no longer available through dynamic tools. Use the codex_app MCP server. If that server is unavailable on this host, task delegation is unavailable."
Initialization evidence (UTC, 2026-09-05):
- SSH initialization succeeded; the affected thread/start completed without error at 08:54:28.233.
- Remote list_threads reached the dynamic-tool execution path at 08:55:31.220.
- No singular codex_app startup entry was found for the affected SSH task. The plural codex_apps server became ready at 08:54:28.841; it is a different server.
- A comparison local task had singular codex_app ready at 09:02:40.877 and exposes all four operations.
This explains the current missing set, but we have not compared the bundle against the last working version, so the exact introducing update is unconfirmed. No configuration or installed files were modified during diagnosis. Credentials and raw logs are omitted.
Activity
github-actions commentedon Sep 5, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
84dnnvbdvp-debug commentedon Sep 5, 2026
Current open-source Codex narrows this to a transport/capability-boundary regression rather than four independent missing-tool bugs.
codex-rs/tui/src/dynamic_tools_mcp.rsmakes the split explicit:ThreadToolTransport::Dynamicinstallsnon_delegation_tool_specs(), whileThreadToolTransport::Mcpremoves dynamic tools and configures an MCP server that exposes the fulltool_specs(). Indynamic_tools.rs, the delegation set removed from Dynamic is currentlycreate_thread,send_message_to_thread, andfork_thread; the MCP server exposes those with approval gating. So a headless SSH host that falls onto Dynamic is expected to retain read/list-style task tools while losing exactly that delegation trio.One useful regression would therefore be at transport selection, not just catalog presence: for a remote/headless host where delegation is supposed to be supported, initialization must either provision the delegation-capable MCP bridge and expose create/send/fork, or explicitly report delegation unavailable. Silently selecting Dynamic while the surrounding product surface/documentation still implies cross-task delegation is the bad state.
There is one additional distinction worth preserving if this is merged into #41580:
handoff_threadis not in the current public TUItool_specs()at all, so its absence is not explained by the public Dynamic-vs-MCP filter. It appears to belong to the Desktop-specificcodex_appsurface described in this report. I’d test that separately from the create/send/fork trio so a fix to the public task-tool transport does not accidentally look like it restored the full Desktop delegation contract.wilson4ever commentedon Sep 8, 2026
Additional reproduction on Desktop 26.901.51231 (build 8109), checked on 2026-09-08. This adds a successful one-way communication probe and another concrete Desktop injection call site to the report above.
Environment
codex-app-toolsplugin: 0.1.3.Communication probe: local -> SSH works; SSH -> local has no callable sender
codex_app__*descriptions and nativemcp__codex_app__*tools are present.mcp__codex_app__send_message_to_threadexactly once, explicitly bindingthreadId: "<ssh-task-id>"andhostId: "remote-ssh-discovered:<alias>", with a unique harmless probe and an ACK request.isError: false, with text content{"threadId":"<ssh-task-id>"}.codex_appMCP send tool with which to send the ACK back to the local task. The retained legacy sender reports:The ACK was obtained by reading the target's response; it was not delivered as an SSH-initiated message. This distinguishes successful local-to-remote transport from the missing remote-side capability. No polling scheduler or repeated sends were used.
Additional installed-bundle evidence
Read-only inspection of this build's
app.asar, internal file.vite/build/main-BT6ViFC-.js, found:ek({hostConfig:e,resourcesPath:...})function explicitly returns early for any non-local host (hostConfig.kind !== "local").desktop-mcp.jsondefinition and constructs themcp_servers.codex_applaunch override for qualifying local hosts.getConfigOverrides:()=>ek(e).This is consistent with the SSH exclusion described in the original issue. It explains the current injection asymmetry; it does not establish which release first introduced it.
Configured MCP is not the same as Desktop-injected MCP
The Mac CLI's configured MCP list does not contain
codex_app, yet the native local-task call above succeeds. The remote CLI's project-cwd query currently listsopenaiDeveloperDocs, but nocodex_app. These observations should not be interpreted as "an empty/configured MCP list proves no injected tools."The same-version runtime checks and successful local-to-SSH probe make a simple CLI-version mismatch or unreachable SSH host an insufficient explanation here. The checked current project registrations and launch/config paths were also correct.
Expected resolution / regression check
Provide the supported, authenticated first-party task-control MCP bridge to SSH-backed tasks before retiring their dynamic delegation path. If this capability is intentionally unsupported, omit obsolete callable definitions and expose an explicit, actionable capability status.
A useful regression check should validate an actual SSH-initiated callback, not only tool descriptions, local-to-SSH delivery, or the ability to read the target's ACK.
No configuration, Hook, Git/project content, installed application files, automation, service, or network settings were modified for this diagnosis. Private project details, task IDs, host aliases, paths, credentials, and raw transcripts are intentionally omitted.
jeffery777 commentedon Sep 11, 2026
補充 2026-09-09 的觀察：本機 Desktop 可操作 SSH 目標，SSH 呼叫者仍自報缺少 create/fork/send。
這是保存的診斷結果，並非在更新版 Desktop 上的新重現。環境為 macOS Desktop
26.901.51231／build8109，透過 Desktop SSH 連到 headless Linux project。另次 shell CLI 查核為0.153.4；服務該遠端回合的實際 app-server 版本未確認。create_thread、fork_thread或send_message_to_thread。codex_app名稱；本機直接名稱查詢為 31 項。遠端仍列有 sidebar／archive 修改工具，因此不能概括為「遠端只有唯讀工具」。read_thread沒有呈現遠端functions.exec的查詢原始輸出或完整 schema。23 項是轉述快照，不是獨立取得的原始 catalog；兩端名稱前綴也不同，不能當 schema 等價比較。本機→SSH 成功證明的是通往該目標的控制路徑，不能證明 SSH 呼叫者自身可發起委派或 callback。我們尚未確認 repository 可修的控制點或引入問題的 Desktop release。
希望 OpenAI 協助釐清：
固定版本的公開證據：
紀錄另保留部分 send completed 但
items=[]、歷史 TUI 來源 fork 失敗而新 Desktop 來源 fork 成功的現象，未將它們歸為同一根因。此次回報沒有新增遠端操作、讀取私人 runtime state、修改設定、安裝 bridge 或切換版本，也未附私人識別碼／主機路徑／完整 config。本觀察亦與 #41248、#40852 重疊；這裡僅補充一次，若另有 canonical tracker 請協助指向。
chac4l commentedon Sep 12, 2026
Additional reproduction on 2026-09-12, with the remote installed CLI reporting
codex-cli 0.154.0.Environment and scope
Directly observed
The source session's complete advertised tool catalog included:
list_threads,list_archived_threads,read_thread,wait_threads;However,
send_message_to_thread,create_thread,fork_thread, andhandoff_threadwere absent. Searching the catalog by both names and descriptions found no alternate send operation or available tool-discovery entry point. In the Code Mode tool object:read_threadsuccessfully returned the intended target's history, andwait_threadssuccessfully returned its active-turn status. The source could therefore inspect the destination but could not invoke the native send operation. No send call reached a destination authorization check or produced a delivery receipt.Reproduction steps
This reproduction does not establish that the problem is specific to side conversations; ordinary remote tasks should also be compared.
Local versus remote behavior
The user reports that this workflow used to work and now appears asymmetric: local tasks can send to remote tasks, while remote tasks cannot send back. That is user-reported history, not a fresh bidirectional A/B test from this session. The exact last working build is unknown.
Please verify local → remote, remote → local, and remote → remote messaging with the same account and explicit authorization, including ordinary tasks and side conversations. Restore the supported native messaging path, or expose an explicit capability reason when it is intentionally unavailable, rather than silently omitting the operation.
Related: #44871 reports a removed dynamic-tool routing error on CLI/app-server 0.154.0. In this sample the operation is missing before invocation, so we cannot claim the same internal cause.
Only a sanitized reproduction and tool names are included here. No private task IDs, messages, host identifiers, addresses, paths, repository details, credentials, or raw logs are attached.
Stix01 commentedon Sep 12, 2026
Additional diagnostic evidence for this existing issue, observed on September 12, 2026. This adds a fresh-task reproduction and an isolated clean-runtime control.
What version of the Codex App are you using (From “About Codex” dialog)?
The About dialog was not inspected.
What subscription do you have?
Not independently verified for this report.
What platform is your computer?
Remote execution host: Ubuntu 24.04.4 LTS, headless Linux.
uname -mprs:The task was viewed from a Mac desktop client and then a phone, while execution remained on the same remote Linux host. The Windows Desktop installation was inspected separately.
What issue are you seeing?
The retained task's callable tool inventory omits
create_thread,fork_thread,send_message_to_thread, andhandoff_thread.An actual call to its retained
codex_app__read_threadtool returned:Switching to a phone did not restore the tools.
A fresh task's diagnostic also reported no callable creation/messaging tools, 146 connector tools under the separate
codex_appsserver, andunknown MCP server 'codex_app'from both MCP resource-discovery calls. Its complete callable-tool inventory was checked as well. No task was created or message sent. The fresh task's results were relayed to this diagnostic; its raw tool output was not independently captured.What steps can reproduce the bug?
codex_appcreation/messaging operations, distinguishing them fromcodex_appsconnector tools.Session identifiers, private project details, and raw logs are omitted for privacy.
What is the expected behavior?
Remote callers should receive a working task-control service for supported creation and messaging operations, with correct host/project association and existing approval handling. If the capability is unsupported in this context, expose an actionable capability status rather than directing the caller to an unavailable replacement.
Additional information
Clean-runtime control: A fresh official
rust-v0.154.0standalone package was downloaded and its published archive digest verified. All six compared package files matched the remote installation byte-for-byte.The fresh binary was started with isolated empty settings, without copying credentials or starting model turns:
create_threadandread_thread, and successfully handled a direct MCP call.mcp_servers.codex_app.enabledandenabled_tools, without a server transport, failed withinvalid transport.This argues against corrupt remote runtime files or a general inability to dispatch MCP calls. It does not establish that the real Desktop task service works remotely.
Read-only Windows bundle inspection: In package 26.908.4834.0, Desktop MCP selection was restricted to the local host. The alternative dynamic-tool filter removed the four task operations above plus
automation_update. Running the extracted filter in isolation reproduced that missing-name set.The bundled
codex-app-toolsadapter required the Desktop native pipe and caller metadata; the inspected native pipe handler supplied a local host ID. The Mac installation was not inspected, and the release that introduced the behavior has not been established.A regression check should verify an actual remote-initiated task operation and its visible result. Tool-name registration or local-to-remote delivery alone would not establish that remote callers can initiate these operations.
zinego commentedon Sep 18, 2026
Additional independently verified reproduction on two remote Linux SSH hosts, observed on 2026-09-16 and reported on 2026-09-18.
Environment
Reproduction and results
hostname,pwd, anddate -u; confirm successful execution and retrieve its result from the local task.send_message_to_thread.session_meta.dynamic_tools.Local-to-remote creation and messages worked, and shell execution was verified on both hosts. Neither remote task could initiate the acknowledgment:
send_message_to_threadwas absent, and zero acknowledgments were sent.Both persisted manifests contained the
codex_appnamespace withlist_threads,read_thread,wait_threads, title/archive and sidebar tools, but omitted all five of:automation_updatecreate_threadsend_message_to_threadfork_threadhandoff_threadThe absence was present at task creation and was independently confirmed through live tool discovery. Explicit user permission did not change tool availability. A remote service restart restored a separate shell-process problem on one host, but did not restore messaging tools; the other host reproduced the same missing-tool set without that shell failure.
Desktop routing evidence
Read-only inspection of the installed bundle found this path:
.vite/build/main-DaMR-wdT.js:LCesetsusesDesktopMcpfromhostId === "local".n.uc(r); the Desktop MCP branch configures the MCP enabled-tool list instead..vite/build/src-CCXHtyvY.js: exportucmaps toTx, which removes the exact five names above from dynamic function tools and from thecodex_appnamespace.A retained older bundle, 26.825.51511 (build 7377), also contains the same exclusion set and a non-Desktop-MCP filtering branch. This is a static comparison only: we have not established the last working release or proven which release introduced the regression.
The public
codex-rs/tui/src/dynamic_tools_mcp.rsalso distinguishes Dynamic (non-delegation tool specs) from MCP, with prompt approval configured for create/send/fork. This is supporting architectural context, not proof of the Desktop product rationale or a reason to bypass approvals.Requested clarification / fix
This report contains only sanitized versions, tool names, bundle code references and reproduction steps. No private hostnames, addresses, paths, task IDs, credentials, conversation contents or raw logs are included. No application patch or security/configuration change was performed.
nanyeglm commentedon Sep 19, 2026
Reproduction update — 2026-09-19
I can still reproduce this Remote SSH task-delegation regression after updating both ends and fully restarting/reconnecting.
Environment
remote-ssh-discovered:<redacted>[mcp_servers.codex_app]configurationDirect tool-surface test in the same SSH-backed task
The task's live tool registry contains the legacy
codex_app__*thread tools. These calls succeeded:list_threads: succeeded and returned local plus connected-host tasksread_thread: succeeded for an existing task on the same Ubuntu hostwait_threads: succeeded and returned the target task's current statusAn explicitly authorized
send_message_to_threadcall to that same valid target failed immediately with:The target task was read back after the rejected call; no new user/delegation input was delivered.
The callable registry contains
codex_app__send_message_to_thread, but there is no callable singularmcp__codex_app__send_message_to_thread(or othermcp__codex_app__*replacement). The plural hosted-app namespace is a different service.This matches the retained-task failure form in #40865 and the local-vs-SSH transport split documented in this issue. Updating the Windows Store app beyond the builds previously reported here, updating the remote CLI/App Server to 0.154.0, rebooting, and reconnecting did not restore the effectful bridge.
No OpenCodeX/provider behavior is involved in this failure: list/read/wait complete before model-provider routing is relevant, while the send is rejected by the app-tool handler itself.
Could a maintainer confirm whether provisioning the singular
codex_appMCP bridge for SSH hosts is planned, or whether Remote SSH delegation is intentionally unsupported? The current guidance still tells the agent to use operations that the SSH path cannot execute.martinbcg commentedon Sep 23, 2026
Same issue here:
Setup
codex-cli 0.156.1, sessions haveoriginator: "Codex Desktop"What's missing
On the remote host, the
codex_appnamespace indynamic_tools(fromsession_metain the rollout files) has the read-only thread tools but not the ones that act on threads:list_threads,read_thread,wait_threads,list_archived_threads,set_thread_title,set_thread_archived,create_worktree,open_in_codex, andget_handoff_statuscreate_thread,handoff_thread,fork_thread,send_message_to_threadtool_searchis available to load them eitherI checked all 15 Desktop sessions on this host from the same day. None of them had these tools, and none ever called them successfully. The tool list comes from the app (
dynamic_tools), so the model or provider used by the session doesn't seem to matter here.Why it hurts
create_thread/handoff_threadfirst", so the agent spends turns looking for tools that aren't there.get_handoff_statusis exposed, but it's useless withouthandoff_thread.spawn_agent. That creates an internal subagent instead of a task in the sidebar, which isn't what the user asked for. In one session, the agent searchedALL_TOOLSforcreate|handoff|fork|send_message, found nothing, spawned a subagent to run a production release, and only mentioned at the end that it couldn't create a task.Expected
Either expose
create_thread/handoff_thread/send_message_to_thread/fork_threadto remote SSH tasks, or stop telling the agent to use them (and hideget_handoff_status) when they're unavailable.wjlevan1 commentedon Sep 25, 2026
I’m running into this too with macOS Codex Desktop connected to a headless Linux host over SSH:
Fresh SSH tasks are missing create_thread, send_message_to_thread, fork_thread, and handoff_thread, while list_threads and read_thread still work. Investigation confirmed the same client-side exclusion path described in this issue.
Coordinating work across remote tasks now requires switching between them and relaying context manually. That breaks the flow of working in Desktop and makes managing multiple remote tasks considerably more cumbersome.
I’d appreciate seeing messaging and delegation restored for headless SSH hosts, whether through the SSH integration or a supported codex_app MCP bridge.
dharamf commentedon Sep 30, 2026
I upgraded desktop versions twice today and randomly tried this and it worked (after weeks of being broken).
desktop build: 26.928.20755
remote: 0.159.2
Can anyone else upgrade and confirm if it works for them as well?
suhailnajeeb commentedon Sep 30, 2026
@dharamf Lucky you!
I'm on the exact same setup:
desktop build: 26.928.20755 (Mac)
remote: 0.159.2 (codex CLI over SSH)
but still no thread messaging tools yet unfortunately.
MtkN1 commentedon Sep 30, 2026
Following up on #42973 (comment): this is still reproducible in my remote SSH environment with the same versions.
26.928.20755, verified from the remote connection logs (app_server.client_name="Codex Desktop",app_server.client_version="26.928.20755").0.159.2after a restart.list_threadsis present in the live tool catalog.send_message_to_thread,create_thread,fork_thread, andhandoff_threadare all absent from the live tool catalog, including deferred tools.So the missing-tool behavior persists here even in a fresh remote chat with Desktop
26.928.20755and remote0.159.2. This check only inspected tool availability and connection logs; no thread messaging was attempted.dharamf commentedon Sep 30, 2026
so upon deeper interrogation my codex had discovered a workaround.
I still lack create_thread, send_message_to_thread, fork_thread, and handoff_thread.
What worked was a lower-level workaround: the task launched the upstream experimental codex app-server over stdio and called JSON-RPC thread/start. Desktop then discovered the persisted session.
Maybe the workaround helps other folks?
rtol5 commentedon Sep 30, 2026
Adding a September 30 result that distinguishes a native messaging workaround from lower-level
thread/startor queue/steer adapters.Our baseline SSH-backed Desktop chats had read-side tools but lacked the callable native sender. Local macOS chats could send natively, including a tested Mac-to-SSH message. We then ran the official, unmodified Linux Desktop alongside the existing remote app-server and exposed its genuine bundled app-tools MCP server through a narrow user-configured binding.
Tested versions:
The Linux Desktop connects to the existing app-server's Unix control socket using
CODEX_APP_SERVER_WS_URL. We did not start a replacement app-server or migrate the original threads. Codex core supplies the real caller/turn metadata to the unmodified app-tools implementation.Observed result:
send_message_to_threadreached an existing original Desktop owner that had been reported asnotLoaded.codex_delegationevent with the correct source-thread identity.config/mcpServer/reloadmade the binding discoverable without restarting the shared app-server. An older owner and the existing coordinator subsequently used it.This restores a tested same-VM native exchange through a manually installed Desktop sidecar; it does not mean the standard SSH integration now exposes the sender. VM-to-Mac-local sending, concurrent owners, restart-during-call behavior and graphical source-link clicking remain unqualified.
The use case is a release coordinator contacting existing independent feature-owner chats and returning integration findings to those same owners, preserving their accumulated implementation context.
Could the SSH integration provide a supported remote app-tools bridge or equivalent native sender, without requiring a full Desktop sidecar on the execution host? A capability diagnostic separating app-tool registration, routing and stale catalogs would also help. We can supply a small sanitized reproduction privately.
laz-jamesfuller commentedon Oct 7, 2026
Additional Windows + WSL reproduction, verified October 7, 2026:
26.930.7945.00.159.2Two existing top-level tasks advertise
list_threads,read_thread, andwait_threads, but omitsend_message_to_thread,create_thread,fork_thread, andhandoff_thread.A retained app-tool call returned the instruction to use the
codex_appMCP server because delegation is unavailable through dynamic tools.Inspection of the installed Desktop bundle confirms local-only Desktop MCP selection and the five-operation exclusion filter on the alternative dynamic path.
Historical evidence: a WSL task's two outbound messaging calls returned success on August 25. Newly created WSL sessions mostly lacked the tool on August 26, with the same CLI version,
0.147.0. The exact introducing Desktop release remains unknown.Is there a supported way to provision the native app-tools MCP bridge for SSH-backed WSL tasks, preserving sender identity and approval handling?
devbotnatanael-hub commentedon Oct 10, 2026
Additional Windows Desktop → Linux SSH / Linux SSH → Windows Desktop comparison, verified on 2026-10-10. Is there a supported way to provision the native, approval-gated
codex_appsender for SSH-backed tasks while preserving source-thread identity?26.1007.2314.0; bundled runtime:0.162.0-alpha.17.2. Remote Linux CLI reports0.162.0.send_message_to_threadfrom Windows to an existing SSH-backed task succeeded. Target readback confirmed receipt and completion.send_message_to_thread. It could not initiate a native return message. Reading its reply from Windows is not a reverse-send success.send_message_to_thread,create_thread,fork_thread,handoff_thread, andautomation_updateon the alternative dynamic-tool path.The required workflow is an SSH-hosted Codex sending prompts directly to ordinary Windows Desktop conversations, including newly created ones. Polling, internal subagents and separate API-owned conversations are not equivalent. The same-VM Linux Desktop sidecar result above is useful, but does not yet establish this cross-host route. Please clarify the supported provisioning/routing path, or whether this remains unavailable. No application binaries, existing configuration, keys or permissions were modified, and no existing services were restarted. Private host/user/project names, conversation IDs, paths and credentials are omitted.
KalebCole commentedon Oct 15, 2026
Additional reproduction on 2026-10-15 with a Mac-to-Mac setup:
list_projects,list_threads, andread_threadare callable. The project is discoverable, butcreate_thread(andhandoff_thread) are absent from the live callable tool registry:typeof tools.codex_app__create_thread === "undefined".create_threadis present and callable. That local chat can see the same remote project and has previously usedcreate_threadto create a chat in a remote project.This extends the reported local-vs-remote difference to an Apple Silicon macOS SSH host, rather than only a headless Linux host. I have not established the exact app build or whether this is an intended policy gate. Expected behavior: an authorized remote project chat can create another user-visible chat in that project, or receives an explicit explanation and supported route when the capability is intentionally unavailable. Project names, paths, and thread IDs are omitted.