macOS: headless Chromium started by agent commands registers as T3 Code and leaves stale Dock tiles #28402

What happened

14 extra "T3 Code (Nightly)" tiles stay in the Dock while one T3 app runs (lsappinfo lists one). They appeared in one burst at 02:00, while a Claude thread ran project commands that launch Playwright's chrome-headless-shell (bunx vitest run ..., a Playwright script). Each headless browser process registered as com.t3tools.t3code, got a Dock tile and exited within seconds; 15 tiles were never removed. This is the part left open when #12975 closed, but the trigger is any agent-run Playwright, not only T3's own preview browser.

Diagnosis

• launchservicesd: CHECKIN:<asn> <pid> com.t3tools.t3code for 19 pids at 02:00:05-02:00:43 (55 in 6 h). tccd for those pids: requesting=headless_shell (~/Library/Caches/ms-playwright/chromium_headless_shell-1243/...), responsible=com.t3tools.t3code (main app pid).
• WindowServer: CreateApplication (T3 Code (Nightly)), then Process death seconds later.
• Dock: 15 Inserting tile at 02:00:15-02:00:43, no matching removal (all other minutes balance). The 14 leftovers all report AXIsApplicationRunning=true.
• Not the env: osascript from an agent shell with __CFBundleIdentifier unset or faked still checks in as com.t3tools.t3code (same as SAKETH11111 in [Bug]: macOS spawns duplicate Dock icons for background helper/server processes #12975). macOS files bundle-less GUI children under their responsible app, and every agent process tree has T3's regular main app as responsible process; no disclaim/LSUIElement identity for server or provider spawns in the source.
• Fix direction: give the server/provider tree an accessory identity (spawn from an LSUIElement helper with responsibility disclaimed). An accessory parent for the server browser alone would miss agent-run browsers. Trade-off: TCC prompts would name the helper ([Bug]: macOS TCC permission prompts attributed to T3 Code are raised by agent CLI probes at startup #5285).

Steps to reproduce

Observed: a Claude thread ran bunx vitest run apps/site ... (tests that launch Playwright headless Chromium), then a Playwright measuring script.
Suggested minimal repro (not run here, the machine was read-only):

1. macOS desktop app, any Claude or Codex thread.
2. Ask it to run: for i in $(seq 15); do node -e "require('playwright').chromium.launch().then(async b=>{const p=await b.newPage();await p.evaluate(()=>navigator.mediaDevices&&navigator.mediaDevices.enumerateDevices());await b.close()})"; done
3. Count tiles: osascript -e 'tell application "System Events" to tell process "Dock" to get name of every UI element of list 1' | tr ',' '\n' | grep -c T3

Version

Desktop app 0.1.7-nightly.20261031.3991 (app started 2026-11-01 01:51, burst at 02:00). The same symptom has shown up on many nightlies since early October. Triage CLI: same version.

Environment

macOS 27.2 (Darwin 27.2.0), Apple Silicon (M3 Pro). Desktop app with its local server. Many Claude Agent SDK 0.3.276 threads in parallel. Playwright chromium_headless_shell-1243. Dock running since 2026-10-05.

Evidence

02:00:24.486 launchservicesd CHECKIN:0x0-0x63ba3b4 27431 com.t3tools.t3code
02:00:24.488 WindowServer CreateApplication: 0x0-0x63ba3b4 (T3 Code (Nightly)) pid: 27431
02:00:24.496 Dock Inserting tile at index: 20 for reason: -[DockBar _handleLaunchNotification:data:]
02:00:32.012 WindowServer Process death: 0x0-0x63ba3b4 (T3 Code (Nightly)) pid: 27431
(no Dock removal follows; the tile is still there 2 h later)

Related issues

#12975 (closed 2026-10-21; this is its open remainder), #13286 (osascript poller fix), #5285 (TCC attribution, same responsibility root), #26966 (agent shells also inherit ELECTRON_RUN_AS_NODE=1; seen here too).

Fix applied or workaround

killall Dock (macOS restarts the Dock at once and redraws it from running apps; no app quits). The tiles come back the next time an agent runs headless Chromium.

Filed by

Claude Opus 5.5 (claude-opus-5-5) as a Claude Code subagent inside T3 Code, following the T3 triage playbook (read-only investigation). Posted at the user's request with gh: this account has no triage permission, so the via-triage label could not be applied, and the prefilled via-triage.yml form URL (5.5k chars) returned a GitHub "Internal server error". Sections follow the via-triage template.