[extension][macOS] activation emits unsupported vscode:// route errors, stale feature warnings, and missing system-skill lookups

Summary

On macOS, the VS Code Codex extension emits a repeated error/warning flood during activation and normal use that does not appear when invoking the Codex CLI directly from Terminal.

I fixed the local setup issues I could safely correct without editing the extension itself, but the remaining symptoms still look extension-side:

• unsupported internal route fetches:
• vscode://codex/local-environments
• vscode://codex/open-in-targets
• repeated app-server/extension warnings about unknown feature keys:
• rmcp_client
• skills
• tui2
• view_image_tool
• repeated request/IPC anomalies:
• No promise for request ID ...
• repeated client-status-changed / thread-stream-state-changed no-handler warnings (likely related to already-filed issues, but included for completeness)
• the extension also tried to read missing files under ~/.codex/skills/.system/openai-docs/assets/... even though a curated openai-docs bundle existed under ~/.codex/vendor_imports/...

Environment

• Extension: openai.chatgpt-26.5311.21342-darwin-arm64
• IDE: VS Code on macOS arm64
• Platform: macOS (Apple Silicon)
• Codex CLI: codex-cli 0.114.0 installed via Homebrew cask

Important isolation detail

The unknown feature warnings do not reproduce when running Codex directly from Terminal:

• codex features list loads successfully and prints the known feature set with no warnings
• a brief direct codex app-server start/stop also produced no stderr output

That strongly suggests the warnings are being introduced by the extension / VS Code path rather than by ~/.codex/config.toml itself.

Correctable local issues I fixed first

I corrected the following local setup problems before filing this issue:

1. Disabled a self-referential codex_self MCP server in my config that was causing separate resources/list 1200s timeouts.
2. Replaced a literal MEMORY_FILE_PATH="$HOME/.memory" env value with an absolute path so the memory MCP server would not receive a non-expanded literal.
3. Removed an unsupported type = "stdio" field from one custom MCP server entry.
4. Restored the missing openai-docs bundle into ~/.codex/skills/.system/openai-docs using the built-in skill installer because the extension was trying to read:

• ~/.codex/skills/.system/openai-docs/assets/openai.png
• ~/.codex/skills/.system/openai-docs/assets/openai-small.svg

Those setup fixes were local-only and separate from the extension errors below.

Remaining extension log evidence

Representative log excerpts:

[error] [CodexMcpConnection] cli:} message="... WARN codex_core::features: unknown feature key in config: rmcp_client\n... unknown feature key in config: skills\n... unknown feature key in config: tui2\n... unknown feature key in config: view_image_tool"

[error] Error fetching errorMessage="local-environments is not supported in the extension" url=vscode://codex/local-environments

[error] Error fetching errorMessage="open-in-target not supported in extension" url=vscode://codex/open-in-targets

[error] No promise for request ID id=...

[warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed

Earlier in the same log stream I also saw:

Error fetching errorMessage="Unable to read file: /Users/<redacted>/.codex/skills/.system/openai-docs/assets/openai.png" url=vscode://codex/read-file-binary
Error fetching errorMessage="Unable to read file: /Users/<redacted>/.codex/skills/.system/openai-docs/assets/openai-small.svg" url=vscode://codex/read-file-binary

Why I think this is extension-side

• Direct CLI startup does not emit the unknown feature warnings.
• The feature names being warned about are not present in my current ~/.codex/config.toml.
• The extension is attempting to fetch internal routes it then immediately says are unsupported in the extension.
• The extension was also looking for openai-docs assets in .system/ even though the curated bundle existed elsewhere, which suggests a bootstrap/path expectation mismatch during skill discovery.

Expected behavior

• Extension activation should not emit unsupported internal route fetch errors for routes it does not implement.
• Extension/app-server startup should not inject unknown feature keys that the installed CLI does not recognize.
• Skill discovery should not reference missing .system/openai-docs assets if the skill was only present under vendor_imports, or it should install/bootstrap the system bundle consistently.
• Request tracking should not emit No promise for request ID ... during routine activation/use.

Related issues

I found existing reports that appear related to the thread-stream-state-changed / local-environments part of the symptom family:

• #13343
• #13583

This report is intended to capture the additional macOS activation issues that do not seem covered there, especially:

• open-in-target not supported in extension
• unknown feature key warnings for rmcp_client, skills, tui2, view_image_tool
• missing openai-docs system-skill asset lookups