`AGENT_BROWSER_ARGS="--ozone-platform=wayland"` is not respected for headed operation

[jasalt]

Browser extra argument environment variables for agent-browser setting Wayland as display backend are not respected for headed usage. Extension initiates headed browser with X11 backend while manually running !agent-browser --headed in same Pi session behaves correctly and opens headed browser using Wayland display backend.

Noticed in Lima (Qemu) VM running on Linux host with Wayland using waypipe for tunneling the display from guest to host.

Rough repro:

0. Both host and quest are Fedora 44 with waypipe via dnf install waypipe. Guest also has chromium installed.
1. Host connecting wayland display to quest VM waypipe --compress lz4 ssh -F /home/user/.lima/default/ssh.config lima-default
2. Environment variables set in guest VM shell session for agent-browser before starting Pi:

export AGENT_BROWSER_ARGS="--ozone-platform=wayland"
export AGENT_BROWSER_HEADED=true

3. When instructing Pi to open example.com in headed browser the extension's agent_browser tool call doesn't seem to pick up the setting but tries to open browser with missing X11 which fails:

agent_browser                                                                   
                                                                                 
 {                                                                               
   "args": [                                                                     
     "open",                                                                     
     "http://example.com",                                       
     "--headless=new"                                                            
   ],                                                                            
   "sessionMode": "fresh"                                                        
 }                                                                               
 Chrome exited early (exit code: 1) without writing DevToolsActivePort           
 (also tried parsing stderr) Chrome exited before providing DevTools URL         
 Chrome stderr:                                                                  
                                                                                 
 [89738:89738:0815/130135.635842:ERROR:ui/ozone/platform/x11/ozone_platform_x11. 
 cc:257] Missing X server or $DISPLAY                                            
   [89738:89738:0815/130135.635900:ERROR:ui/aura/env.cc:246] The platform failed 
 to initialize.  Exiting. 

Managed session outcome: Fresh launch became current, but this tool call failed 
 after launch.                                                                   
 Recovery:                                                                       
 - Continue with sessionMode "auto" on the current session, or inspect           
 failureCategory / qaPreset to fix the post-launch failure.                      
 - Run doctor only if later browser commands also fail.                          
 - Full session names and transition details remain in                           
 details.managedSessionOutcome.                                                  
 Cleanup warning: Automatic close of the previous wrapper-managed session        
 failed, so it remains wrapper-owned. Use details.managedSessionOutcome for its  
 exact identity and close it explicitly when safe.                               
                                                                                 
 Result category: failure; failureCategory: upstream-error; Pi tool isError:     
 true.       

4. Running ! agent-browser open --headed example.com manually works as expected opening browser Wayland window on host.

Workaround in this scenario is disabling the extension and using the agent-browser CLI directly.

Might apply to MacOS host also if using https://github.com/J-x-Z/cocoa-way or https://github.com/J-x-Z/waypipe-darwin.

[nighty90]

I'm running into a similar issue too.

I'd like to scale the page content in headed mode via --force-device-scale-factor. I pass it through ~/.agent-browser/config.json as "args": "--force-device-scale-factor=1.5", but it has no effect. The extension forces agent-browser to use an empty config file for actual browser operations, so my config file is never read.

My current workaround:
In dist/extensions/agent-browser/lib/managed-session-restore.js, make getManagedSessionRestoreConfigEnv return {} so the pinned empty config is skipped and ~/.agent-browser/config.json is read again:

export async function getManagedSessionRestoreConfigEnv(restoreEnv, pinForOwnedClose = false) {
    return {} // skip pinning the empty config
    const path = await ensureManagedSessionRestoreEmptyConfig(process.platform);
    return path ? { [AGENT_BROWSER_CONFIG_ENV]: path } : undefined;
}

Would love to see display-related settings configurable in the extension's own config. Thanks for the work on this.

[fitchmultz]

The wrapper-owned launch-env clearing and pinned empty config were removed in v0.6.0; current npm 0.6.5 forwards caller AGENT_BROWSER_ARGS, headed settings and config unchanged. Could you retry the Wayland/waypipe/Lima case and the passive config scale-factor case on the affected setup? If either still fails, please share sanitized wrapper/Pi/CLI/browser versions, display topology and Chrome error text. We have verified forwarding, not a real Wayland desktop, so we are not closing from a macOS-only test.

[nighty90]

Retested the passive-config case on 0.6.13 — it works, no patches needed anymore on my side. I did not test the AGENT_BROWSER_ARGS environment-variable path though.

Environment

• pi-agent-browser-native 0.6.13
• agent-browser 0.37.1
• Pi 0.85.1
• WSL2 + WSLg (DISPLAY=:0, WAYLAND_DISPLAY=wayland-0)
• Windows host display: 2560x1600
• config: ~/.agent-browser/config.json = {"headed": true, "args": "--force-device-scale-factor=1.5"}

Observation

• screen 1706x1066 (= 2560/1.5)
• devicePixelRatio 1.5
• Chrome's command line shows --force-device-scale-factor=1.5 with no --headless
• a headed window did appear on the Windows desktop