自从Free账号禁用gpt-5.4之后，我的sub2api开始频繁报错，提示一直有频繁的gpt-5.4请求,
同时近期又有帖子说到Free账号调用5.4大概率会被风控。
于是我拉取了一份gpt-5.4调用日志 发现Codex会自动使用gpt-5.4-medium去调用ambient suggestions后台任务去发送信息
127.000.000.001.62454-127.000.000.001.08080.txt (34.4 KB)
Free号池记得关掉这个功能 触发频率还是极其高的
二更
有人提到还会涉及到隐私问题
EYHN
bug
app
session
computer-use
browser
## Summary I observed Codex Desktop / Computer Use operating my real Google Chr…ome profile in the background and opening Gmail. After inspecting local Codex logs, this appears to have been triggered by Codex Desktop's built-in `ambient_suggestions` workflow, not by an explicit user request in the visible conversation. The background workflow used Computer Use against Chrome, opened or navigated to Gmail Inbox, captured Gmail UI state, clicked Gmail labels, and attempted to type a Gmail search query. The generated ambient suggestion later referenced information visible from a Gmail message. This is a serious privacy and safety issue because a proactive suggestion feature operated a logged-in browser and accessed email content without a clear foreground task, confirmation, or discoverable session/audit trail in the normal thread UI. ## Environment - Product: Codex Desktop - Platform: macOS - Date observed: 2026-05-25 - Timezone: Asia/Shanghai - Workspace involved: local project at `$HOME/Projects/mini-control` - Computer Use service path observed: - `$HOME/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService` - Computer Use client path observed: - `$HOME/.codex/plugins/cache/openai-bundled/computer-use/1.0.799/.../SkyComputerUseClient` I have redacted local usernames, email addresses, account identifiers, screenshots, and message contents from this report. ## What happened At approximately `2026-05-25 16:08:59 +0800`, I saw Codex Computer Use interact with my Chrome browser and open Gmail. This was surprising because I had not asked the visible Codex conversation to open Gmail or inspect my email. Local logs show a hidden/background Codex thread associated with `ambient_suggestions`: - Background thread ID: `019e5e2c-2e51-7293-832d-8c2edb680293` - Turn ID: `019e5e2c-31cd-7c11-85c6-e15498707659` - Model request timestamp: `2026-05-25 08:10:28 UTC` / `2026-05-25 16:10:28 +0800` - Model completion timestamp: `2026-05-25 08:10:53 UTC` / `2026-05-25 16:10:53 +0800` - Log source: `$HOME/.codex/logs_2.sqlite` - The normal Codex session/thread database did not show this as a regular user-visible thread. The captured model context shows that this was a proactive suggestion generation task. The task prompt instructed the model to generate personalized suggestions for the local project by inspecting project files and connected apps, including recent events such as unread emails. ## Evidence from local logs ### 1. Computer Use service directly interacted with Chrome System/app logs around the observed time show `SkyComputerUseService` moving/clicking a Chrome window and posting an HID event: ```text 2026-05-25 16:08:58.787 +0800 SkyComputerUseService log0090 54 2026-05-25 16:08:58.838 +0800 SkyComputerUseService log0091 636.000000 629.000000 28908 2026-05-25 16:08:59.xxx +0800 SkyComputerUseService HID event posted ``` The service binary is the OpenAI-signed Codex Computer Use service: ```text $HOME/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService ``` TCC/log attribution also associated the Computer Use client with Codex Desktop: ```text responsible identifier: com.openai.codex responsible path: /Applications/Codex.app/Contents/MacOS/Codex requesting identifier: com.openai.sky.CUAService.cli requesting path: $HOME/.codex/plugins/cache/openai-bundled/computer-use/1.0.799/.../SkyComputerUseClient ``` ### 2. Codex Desktop created a hidden/background browser-use route Desktop logs around the same period show a browser-use route for an unknown/background conversation: ```text Received turn/started for unknown conversation conversation_id: 019e5e2c-2e51-7293-832d-8c2edb680293 pipe: /tmp/codex-browser-use/0582e698-0881-4d40-a2fb-1f678d230429.sock ``` This conversation was not visible as a normal persisted thread in the usual Codex session database. ### 3. The background context exposed Computer Use tools The captured `response.create` request for the `ambient_suggestions` turn included: ```text model: gpt-5.4 reasoning effort: medium input items: 80 context size: 1,488,772 characters tools included: exec_command, web_search, mcp__computer_use__, ... sandbox policy in metadata: ReadOnly network access in metadata: false ``` Even though the sandbox metadata was `ReadOnly`, the context included Computer Use calls that operated the user's live Chrome UI. ### 4. The ambient_suggestions prompt asked for connected-app context The local logs show a proactive suggestion prompt equivalent to: ```text Generate 0 to 3 hyperpersonalized suggestions for what this user can do with Codex in this local project: $HOME/Projects/mini-control Get an understanding of the user's intent and goals by deeply viewing their connected apps... Your suggestions must be based on recent events; e.g. recent Slack messages, unread emails, newly created issues, etc. ``` This means the Gmail access was not a random system event. It was connected to the ambient suggestions workflow's instruction to inspect connected apps and recent email/message context. ### 5. Computer Use inspected Chrome and clicked into Gmail The captured context contains Computer Use transcript items against `Google Chrome`, including `get_app_state`, `click`, and `set_value`. The relevant click sequence was: ```json {"app":"Google Chrome","element_index":"560"} {"app":"Google Chrome","element_index":"18"} {"app":"Google Chrome","element_index":"477"} {"app":"Google Chrome","element_index":"54"} {"app":"Google Chrome","element_index":"83"} {"app":"Google Chrome","element_index":"35","value":"label:github \"mini-control\""} ``` Observed state transitions in the Computer Use outputs: - `element_index: 560` was Chrome's `New Tab` button. - After the New Tab click, Chrome showed Gmail/Inbox shortcuts and bookmarks. - A later Chrome state showed Gmail Inbox loaded: - Window title contained `Gmail` - Address bar showed `mail.google.com/mail/u/0/#inbox` - `element_index: 83` corresponded to a Gmail label link for GitHub mail. - `element_index: 35` corresponded to the Gmail search field. - The workflow attempted to set the search value to: ```text label:github "mini-control" ``` That final value-setting action was stopped by the user. ### 6. Gmail content influenced the generated suggestion The final ambient suggestions included a suggestion based on a Gmail-visible account funding warning related to the local project deployment provider. I am not including the email sender, account, subject, or body in this public issue, but the local context clearly tied the generated suggestion to information visible in Gmail. One of the returned suggestions had: ```json {"appId":"com.google.Chrome"} ``` ## Expected behavior Ambient/proactive suggestions should not operate the user's real browser or inspect logged-in apps such as Gmail without an explicit, visible, per-run authorization. At minimum, I would expect: - A clear foreground prompt before any background suggestion workflow uses Computer Use. - Explicit per-app consent before Chrome/Gmail is inspected. - No clicking, typing, or navigation in real user apps from a passive suggestion feature. - A visible, user-accessible audit trail showing: - Which background task ran. - Which model/session initiated it. - Which app was inspected. - Which Computer Use actions were taken. - Which data source contributed to each suggestion. - A setting to fully disable `ambient_suggestions` and connected-app inspection. - A stronger permission boundary between "read local repository" and "operate logged-in browser/email". ## Actual behavior - A background `ambient_suggestions` task used Computer Use. - It enumerated local/connected apps. - It successfully inspected Google Chrome while some other app probes were denied. - It clicked Chrome UI, opened a new tab, navigated into Gmail Inbox, clicked Gmail labels, and attempted a Gmail search. - It generated a suggestion based on Gmail-visible content. - The task was not easily discoverable as a normal user-visible Codex thread. - The local plaintext model reasoning was not available; reasoning items were encrypted, so I could infer behavior only from tool calls and tool outputs. ## Why this is a security/privacy problem This behavior creates several risks: - Email privacy leakage: sender names, subjects, snippets, and account-specific details can enter model context. - Lateral overreach: Chrome contains logged-in sessions for many sensitive websites, not just Gmail. - Accidental mutation: Computer Use can click, type, submit, delete, archive, send, or otherwise change remote app state. - Prompt/context injection: email or webpage content can influence a background agent that has tool access. - Audit gap: the background thread was not presented like a normal visible Codex task, making it difficult to understand or stop. - Consent ambiguity: the user may believe they authorized the visible task only, while background suggestions reuse connected-app access. ## Related public issues I found several related issues that point to the same class of problem, though I did not find an exact existing issue for "ambient_suggestions opened Gmail via Computer Use": - [openai/codex#19876](https://github.com/openai/codex/issues/19876) - ambient suggestion command approval notifications can route to a hidden/stale/inaccessible task. - [openai/codex#18541](https://github.com/openai/codex/issues/18541) - ambient suggestions can run after a normal thread ends and trigger hooks. - [openai/codex#21722](https://github.com/openai/codex/issues/21722) - request to expose a supported way to disable browser-use ambient network initialization. - [openai/codex#20852](https://github.com/openai/codex/issues/20852) - request for per-agent Computer Use session/window lease/audit trail. ## Suggested fixes Please consider: 1. Disable Computer Use, Chrome, browser-use, and connected-app tools for `ambient_suggestions` by default. 2. Require explicit user approval before any ambient/proactive feature can inspect connected apps. 3. Treat Chrome as a high-risk container because it grants access to many logged-in websites. 4. Make Gmail/email access a separate, clearly named permission, not an implicit consequence of Chrome access. 5. Never allow passive suggestion generation to click/type/navigate in real user apps. 6. Add a visible "Background tasks" / "Ambient suggestions" audit view. 7. Persist hidden ambient suggestion sessions in the normal session history, or provide an equivalent first-class audit log. 8. Include a per-suggestion provenance field showing which data sources were used. 9. Provide a global setting to disable ambient suggestions and connected-app context gathering. 10. Show an immediate notification when Computer Use is invoked by a background task, including the responsible thread/session ID. ## Attachments / data I can provide privately I can provide redacted excerpts from: - `$HOME/.codex/logs_2.sqlite` - Codex Desktop app logs around `2026-05-25 16:06:52` to `2026-05-25 16:10:53 +0800` - Sanitized Computer Use transcript entries showing the Chrome/Gmail click sequence - Sanitized local audit markdown summarizing the behavior I am intentionally not attaching raw logs publicly because they contain private Gmail, browser, workspace, and account context.
4 个帖子 - 3 位参与者