[Bug]: macOS stdio MCP repeatedly surfaces OpenScreen and accumulates long-lived processes in Codex
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 38/100
- Issue 類型
- 缺陷
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
- 技術堆疊
- electron, macos, typescript
研究方向
Start by locating the stdio MCP entry point and macOS app startup code, then trace how MCP startup affects Electron windows and how client sessions are cleaned up. The report gives no source files or tests, and a single-client reproduction is still needed; first reproduce with the documented Codex configuration and inspect process and window behavior. Done means unrelated Codex use no longer repeatedly surfaces OpenScreen UI or leaves unnecessary MCP processes running.
由索引模型根據 Issue 內容生成。
描述
Search existing issues
- I searched existing issues. #1137 is related to concurrent CLI processes but describes Chromium profile contention, not this repeated popup/process accumulation symptom.
Describe the bug
After following the documented demo skill setup and registering the installed macOS app as a global Codex stdio MCP server, OpenScreen repeatedly popped up during normal Codex usage, without an explicit recording request at those moments. Multiple long-lived Openscreen mcp processes accumulated in the background.
On November 6, 2026, process inspection found 38 OpenScreen MCP main processes. Their parents were Codex app-server processes (desktop bundled Codex and Homebrew Codex). Some instances had been alive for over a day; others were newly started. During cleanup, 111 OpenScreen app processes including helpers were sent SIGTERM, and a subsequent check found zero remaining.
The user-facing popup symptom and process accumulation are observed. I have not isolated whether the popup is a normal window, Dock activation, or another Electron startup UI, nor whether the instance accumulation is caused by MCP client lifecycle, OpenScreen lifecycle, or their interaction. No claim that all 38 processes displayed windows simultaneously.
Expected behavior
Registering the documented stdio MCP integration should not repeatedly surface OpenScreen UI during unrelated chats. Multiple client sessions should have a supported lifecycle that avoids leaving unnecessary Electron processes running. Recording or editing UI should appear only when requested, or otherwise be clearly documented.
To reproduce (observed workflow)
-
Install OpenScreen 2.1.2 on macOS.
-
Follow the install-page instructions:
npx skills add getopenscreen/openscreen --skill openscreen-demo -y. -
Confirm the installed executable's
helpoutput listsmcp. -
Register it using:
codex mcp add openscreen -- /Applications/OpenScreen.app/Contents/MacOS/Openscreen mcpResulting config:
[mcp_servers.openscreen] command = "/Applications/OpenScreen.app/Contents/MacOS/Openscreen" args = ["mcp"] -
Use Codex across chats/sessions over time. Desktop and Homebrew Codex app-server processes were both present in this environment.
-
Observe repeated OpenScreen popups and accumulated processes with this exact main-process command:
/Applications/OpenScreen.app/Contents/MacOS/Openscreen mcp
This has not been reproduced on a clean profile or with only one MCP client. A single-client minimal reproduction is still needed.
Environment
- OpenScreen version/build: 2.1.2 / 2.1.2 (read from the installed app's Info.plist)
- Bundle identifier:
com.etiennelescot.openscreen - macOS: 26.5.2
- Architecture: arm64 / Apple Silicon
- MCP transport: stdio, global Codex configuration
- Device: Mac laptop
- Browser: not applicable
Workaround and limitations
Removed the global integration with codex mcp remove openscreen, stopped the remaining OpenScreen processes, and uninstalled the app at the user's request. Recordings and projects were preserved. There were zero OpenScreen processes immediately after cleanup; long-term popup recurrence has not been assessed.
Please investigate whether macOS MCP startup can remain genuinely headless and how concurrent MCP client instances should be managed. I cannot infer the internal cause from the process listing alone.
- 主要語言
- TypeScript
- 星號
- 3.7k
- 分支
- 231
- 平均合併
- 19 小時 7 分鐘
- 30 天內合併 PR
- 266
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
getopenscreen/openscreen 的其他 Issue
-
Native review wanted: machine-translated recording bar tooltips (14 locales)可能重新可做 @auberginewly 於 29 天前認領,目前沒有進行中的 PR。 未關閉good first issue help wanted
難度 2/5 1-3 小時 新手友好度 68/100
getopenscreen/openscreen#913 · 5 則留言 ·
維護者通常 1 天內回覆
-
[Bug]: macOS — takes end with SCStreamErrorDomain -3821 "Stream was stopped by the system" when the disk is low on free space可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉
難度 4/5 3-5 天 新手友好度 54/100
getopenscreen/openscreen#1496 ·
維護者通常 1 天內回覆
-
enhancement
難度 5/5 一週以上 新手友好度 35/100
getopenscreen/openscreen#1494 ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 48/100
getopenscreen/openscreen#1493 ·
維護者通常 1 天內回覆
-
enhancement
難度 3/5 1-2 天 新手友好度 55/100
getopenscreen/openscreen#1490 ·
維護者通常 1 天內回覆
查看 getopenscreen/openscreen 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 68/100
維護者通常 1 天內回覆
-
documentation easy good first issue help wanted
難度 1/5 1-3 小時 新手友好度 83/100
維護者通常 1 天內回覆
-
Billion-context documentation addendum: nudge is independent of window occupancy. | billion-context 文档补充:nudge 与窗口占用无关可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉
難度 1/5 1-3 小時 新手友好度 86/100
ranxianglei/billion-context#5893 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 79/100
microsoft/monaco-editor#5575 ·
維護者通常 1 天內回覆
-
enhancement
難度 2/5 1-3 小時 新手友好度 68/100