Launching a Flatpak-packaged browser (Edge flatpak) via --executable-path fails: DevToolsActivePort lives in a private /tmp

Summary

Launching a browser packaged as a Flatpak app via --executable-path can never complete: agent-browser spawns the browser with a temp --user-data-dir under /tmp, but Flatpak gives the app a private /tmp, so the DevToolsActivePort file the daemon waits for never appears on the host. The command fails after ~30 s with a generic socket timeout, the two retries each spawn another browser, and each spawned instance keeps running for ~30 s after the error has already been reported.

Environment

• agent-browser 0.39.1 (node 26.12.0), Pop!_OS 24.04 LTS (Ubuntu 24.04 base)
• Microsoft Edge 155.0.4283.45 installed as a Flatpak (com.microsoft.Edge, flathub — the way flatpak install com.microsoft.Edge installs Edge on Linux)
• /usr/bin/microsoft-edge-stable is a two-line shim:

  #!/bin/bash
  exec /usr/bin/flatpak run com.microsoft.Edge "$@"

Repro (reproduced 3/3)

# with no `profile` pinned in ~/.agent-browser/config.json
agent-browser --session repro --executable-path /usr/bin/microsoft-edge-stable open about:blank

Observed, exit code 1 after ~30 s:

✗ Failed to read: Resource temporarily unavailable (os error 11) (the command reached the daemon but no response came back; it may or may not have run, so it was not retried)

The daemon log only says:

[daemon] Debug logging started for session: ...
[chrome] Launch attempt 1/3 failed, retrying in 500ms...
[chrome] Launch attempt 2/3 failed, retrying in 500ms...

Root cause

The browser does start — a headless Edge inside the Flatpak sandbox:

$ pgrep -af 'agent-browser-chrome-'
bwrap --args 78 -- edge --remote-debugging-port=0 … --user-data-dir=/tmp/agent-browser-chrome-<uuid> --headless=new …
/app/extra/msedge … --user-data-dir=/tmp/agent-browser-chrome-<uuid> …

Inside the sandbox the port file exists:

$ flatpak run --command=sh com.microsoft.Edge -c 'cat /tmp/agent-browser-chrome-<uuid>/DevToolsActivePort'
36103
/devtools/browser/4d55fb44-2cbf-42e6-9b43-84f0ce7bc3f3

On the host it does not:

$ ls /tmp/agent-browser-chrome-<uuid>
ls: cannot access '/tmp/agent-browser-chrome-<uuid>': No such file or directory

cli/src/native/cdp/chrome.rs:539 picks std::env::temp_dir()/agent-browser-chrome-<uuid> as the user-data-dir when --profile is not set, and wait_for_devtools_active_port() (chrome.rs:884/939) polls that host path — so it can only ever time out (Timeout waiting for DevToolsActivePort, chrome.rs:968). Every attempt uses a fresh uuid, so each of the 3 attempts (max_attempts = 3, chrome.rs:757) spawns a full browser.

Secondary effects

• The CLI surfaces the socket read timeout (EAGAIN), not the daemon's actual launch error: the CLI gives up after ~30 s while the daemon's launch protocol can run 3 × 30 s (per-attempt deadline, chrome.rs:879) plus retry delays. The only hint the user gets is "it may or may not have run".
• After the error has already been shown, a full headless browser keeps consuming CPU/RAM until its attempt window expires. Measured after the command returned: 20 processes at +10 s and +40 s, gone by +100 s. agent-browser close reaps the live attempt promptly, but a user who only sees the error doesn't know to run it. (Cf. #1401 for the zombie-process variant of this cleanup path.)

Verified workarounds

1. Point --profile inside the app's sandbox-visible data directory (persistent across restarts):

   agent-browser --profile ~/.var/app/com.microsoft.Edge/config/agent-browser-profile \
     --executable-path /usr/bin/microsoft-edge-stable open about:blank   # works, 1-4 s

2. Keep temp profiles, but move TMPDIR into a sandbox-visible directory (chrome.rs:539 honors TMPDIR):

   TMPDIR=~/.var/app/com.microsoft.Edge/config/ab-tmp \
     agent-browser --executable-path /usr/bin/microsoft-edge-stable open about:blank  # works, 2 s

Suggested improvements

1. When DevToolsActivePort times out and the child process is still alive, fail fast with a targeted message (sandboxed browsers keep /tmp private; suggest a --profile/TMPDIR under ~/.var/app/<app-id>/…). Even just surfacing the daemon's "Timeout waiting for DevToolsActivePort" instead of the CLI's EAGAIN would make this diagnosable.
2. Reap the process tree of a failed attempt before starting the next one, so nothing keeps running after the error is reported.
3. Optionally detect Flatpak shims (flatpak run inside the executable) and default the user-data dir to ~/.var/app/<app-id>/…, or document the Flatpak case next to --executable-path.

Related

#1791 (WSL2: port-0 listener not reachable), #1710 (Windows: browser exits early), #1401 (failed launch leaves unreaped children), #1371 (orphaned headless Chrome helpers) — different triggers, same launch-diagnostics family.