Background ambient suggestions invoked mutating MCP desktop tool (`app.click_app`) without visible user action

Summary

A background Codex Desktop path appears to invoke third-party MCP desktop automation tools while generating ambient suggestions/context. In this case it called a mutating desktop tool, app.click_app, against Chrome even though the user did not trigger any visible Codex UI action.

This is both a privacy/provenance issue and a safety issue: background suggestion/context collection should not be able to change local desktop state.

Environment

• Codex CLI: 0.135.0
• MCP client logged by the server: name='codex-mcp-client' title='Codex' version='0.135.0-alpha.1'
• Platform: macOS arm64
• Install method: Homebrew
• MCP server type: local Streamable HTTP MCP server on 127.0.0.1
• Timezone of timestamps below: Asia/Shanghai

What happened

The MCP server log shows real CallToolRequest entries after 2026-06-01 17:50:09. These were not initiated from the visible Codex conversation and did not appear in the normal visible-thread codex_core::mcp_tool_call logs.

Sanitized timeline:

• 2026-06-01 17:50:09.315 — app.list_app, trace b6bd3c5c09264a54b8b7f5c4a287e386
• 2026-06-01 17:50:14.438 — app.get_app_state for Lark, trace 1b3eca36b8ef4cfab6562b17b575257b
• 2026-06-01 17:50:16.006 — app.get_app_state for Chrome, trace ee6e1bf8fb1b47cdbc06b1ef209eea09
• 2026-06-01 17:50:27.133 — app.get_app_state for Calendar, trace b3c1f72245a046efafaf7eaae696bf34
• 2026-06-01 17:51:08.338 — app.click_app for Chrome, element index 11104, trace 50b5058773904f578b310e30d8929309, succeeded
• 2026-06-01 17:51:17.195 — app.click_app for Chrome, element index 2158, trace fe71754a272a4908a9ae547dd10238f9, succeeded
• 2026-06-01 17:51:30.021 — app.click_app for Chrome, element index 362, trace f42c40a7bf2f4f1fbfddcb326c40b07f, succeeded
• 2026-06-01 17:51:49.260 — app.list_app, trace 76060379bf4248d6963ad0a234bdb84a
• 2026-06-01 17:51:49.826 — app.click_app for Chrome, element index 550, trace 3fde83de482048148738bc97239a5994, succeeded
• 2026-06-01 17:53:22 through 17:53:27 — background-looking state collection for VS Code, Lark, Calendar, and Chrome

The server log recorded the caller as:

name='codex-mcp-client' title='Codex' version='0.135.0-alpha.1'

Evidence pointing to ambient suggestions/background context collection

Local Codex logs showed short background-looking sessions around the same time using gpt-5.4-mini/gpt-5.4 and producing JSON suggestions. A local ambient suggestions artifact was updated shortly afterwards:

~/.codex/ambient-suggestions/<redacted>/ambient-suggestions.json
modified: 2026-06-01 17:55:02 Asia/Shanghai

Those suggestions referenced the same classes of desktop state that were collected by the MCP calls, including Chrome, VS Code, Lark, and Calendar. The visible user conversation/session did not contain corresponding mcp__... tool calls for these actions.

Expected behavior

• Background/ambient suggestion generation should only use read-only context providers.
• It should not call mutating MCP tools such as click, key press, text input, or arbitrary action execution.
• Any mutating MCP tool call should require explicit visible user intent and should be attributable to a visible thread/session.
• MCP server logs should include enough provenance to distinguish visible assistant tool calls from background features such as ambient suggestions.

Actual behavior

A background Codex client path appears to have invoked app.click_app against Chrome multiple times without a visible user action.

Suggested fixes

• Restrict ambient suggestions/background context collection to an explicit read-only MCP allowlist.
• Honor MCP tool metadata such as readOnlyHint/mutating annotations when selecting tools for background tasks.
• Block click/key/type/action tools from all background contexts.
• Add source/provenance metadata to MCP calls, for example visible-thread, ambient-suggestions, browser-use, etc.
• Consider requiring confirmation for any third-party MCP tool that can mutate local desktop state, even if the MCP server is configured globally.

I have omitted local paths, UI tree contents, and application-specific document/window text from this report to avoid leaking private desktop context.