[GH-ISSUE #3414] [Bug] Owned Electron capture drops the selected X11 authorization path #1273

New issue

Closed

opened 2026-10-16 21:03:39 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-16 21:03:39 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3414

An explicitly selected authenticated X11 display cannot launch an owned Electron capture because the production launch environment drops XAUTHORITY.

Reproduced on Linux x64, ordinary uid1004, real official Electron44.7.2, Xvfb/xauth, and REA 8dde6370d0809ad04cda3342d4e6f290f48aa063. DISPLAY and XAUTHORITY were explicitly supplied to the MCP server. A public capture_electron_scenario request with an owned minimal application returns execution_failure:

Authorization required, but no authorization protocol specified
Missing X server or $DISPLAY
The platform failed to initialize. Exiting.

safeElectronEnvironment in src/browser/PlaywrightElectronActiveProvider.ts forwards DISPLAY/WAYLAND_DISPLAY, but excludes the selected X11 authorization-file path. The caller's display is available to the parent application; the child loses the credential-location input it needs. Do not disable X11 authentication or silently choose another display to repair this.

An isolated load-hook counterfactual adds only XAUTHORITY to the actual MCP runtime environment list, leaving stock files unchanged. It eliminates the X11 launch failure and reaches an independent fail-closed ownership/cleanup failure with real Electron application metadata. Full successful capture/cleanup is not claimed; that remaining limitation needs separate verification. The first unbundled-facade hook did not affect the actual MCP chunk and is not counted as a valid counterfactual.

The real verifier also needs explicit display inputs in its narrow MCP environment and must report the primary launch error before assuming a partial capture exists; its current cleanup assertion masks that error. Preserve resource ownership and existing cleanup guards while fixing these directly affected test consumers. The production environment file is unchanged on current main 322506d0c0d39d3cd1e2e1c285c2cc23cfa73ee7.

Originally created by @N0zoM1z0 on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3414 An explicitly selected authenticated X11 display cannot launch an owned Electron capture because the production launch environment drops `XAUTHORITY`. Reproduced on Linux x64, ordinary uid1004, real official Electron44.7.2, Xvfb/xauth, and REA `8dde6370d0809ad04cda3342d4e6f290f48aa063`. `DISPLAY` and `XAUTHORITY` were explicitly supplied to the MCP server. A public `capture_electron_scenario` request with an owned minimal application returns `execution_failure`: ```text Authorization required, but no authorization protocol specified Missing X server or $DISPLAY The platform failed to initialize. Exiting. ``` `safeElectronEnvironment` in `src/browser/PlaywrightElectronActiveProvider.ts` forwards `DISPLAY`/`WAYLAND_DISPLAY`, but excludes the selected X11 authorization-file path. The caller's display is available to the parent application; the child loses the credential-location input it needs. Do not disable X11 authentication or silently choose another display to repair this. An isolated load-hook counterfactual adds only `XAUTHORITY` to the actual MCP runtime environment list, leaving stock files unchanged. It eliminates the X11 launch failure and reaches an independent fail-closed ownership/cleanup failure with real Electron application metadata. Full successful capture/cleanup is **not** claimed; that remaining limitation needs separate verification. The first unbundled-facade hook did not affect the actual MCP chunk and is not counted as a valid counterfactual. The real verifier also needs explicit display inputs in its narrow MCP environment and must report the primary launch error before assuming a partial capture exists; its current cleanup assertion masks that error. Preserve resource ownership and existing cleanup guards while fixing these directly affected test consumers. The production environment file is unchanged on current main `322506d0c0d39d3cd1e2e1c285c2cc23cfa73ee7`.

bsakaguchi referenced this issue

2026-10-17 21:09:53 +00:00

[PR #1273] [MERGED] fix(files): reject nonregular capture and JSON inputs #2755

bsakaguchi closed this issue

2026-10-31 00:30:23 +00:00

bsakaguchi commented

2026-10-31 00:30:24 +00:00

Author

Owner

@matbrgz commented on GitHub (Oct 19, 2026):

Cross-referencing with sibling Linux Electron capture report #4282 ([Bug] Linux Electron capture cannot verify owned lineage: Chromium processes do not expose REA_PROCESS_RUN_ID in /proc/<pid>/environ). Both issues address Linux-specific Electron capture authorization boundaries (X11 authority forwarding and Chromium process environment scrubbing).

Consolidated under Cluster AD (Linux Electron Owned Lineage & X11 Authorization) in tracker #4330.

@matbrgz commented on GitHub (Oct 19, 2026): Cross-referencing with sibling Linux Electron capture report #4282 (`[Bug] Linux Electron capture cannot verify owned lineage: Chromium processes do not expose REA_PROCESS_RUN_ID in /proc/<pid>/environ`). Both issues address Linux-specific Electron capture authorization boundaries (X11 authority forwarding and Chromium process environment scrubbing). Consolidated under **Cluster AD (Linux Electron Owned Lineage & X11 Authorization)** in tracker #4330.

bsakaguchi referenced this issue

2026-10-31 00:39:48 +00:00

[GH-ISSUE #5561] [Bug] IDA doctor stops responding when its registration path is a FIFO #3386

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#1273

No description provided.

Rows
Columns