Fix screenshot/browser file output not deliverable in FoxFang runtime

[potlock-support]

Summary

Headless browser screenshot generation can partially work in the FoxFang runtime, but the resulting screenshot file is not reliably deliverable or accessible for follow-up use.

In practice, this means an agent may be able to render a page with Chromium, but then fail to:

• save the screenshot to the expected workspace path
• verify the file exists afterward
• attach or send the generated image back to the user

This breaks the end-to-end screenshot workflow.

Problem

FoxFang currently appears to have a runtime bug or environment mismatch affecting browser screenshot output and file delivery.

During practical use with chromium-browser in headless mode against https://reply.cash, the following behavior was observed:

1. Chromium could launch and render the page.
2. Writing directly to the workspace path failed with a permission error.
3. Writing to /tmp/...png reported success (... bytes written to file ...).
4. Immediately afterward, the file was not available for normal access or delivery.
5. As a result, the agent could not send the screenshot back to the user.

This suggests the problem is not only browser launch, but the full pipeline of:

render -> write file -> verify file -> attach/deliver image

Reproduction

Example command used:

chromium-browser --headless --no-sandbox --disable-gpu --hide-scrollbars --window-size=1440,2000 --screenshot=/tmp/reply-cash-homepage.png https://reply.cash

Observed runtime behavior included:

• workspace write failure:

Failed to write file /root/.foxfang/workspace/reply-cash-homepage.png: Permission denied (13)

• temporary path write appearing to succeed:

12904 bytes written to file /tmp/reply-cash-homepage.png

• immediate access failure afterward:

ls: cannot access '/tmp/reply-cash-homepage.png': No such file or directory

Expected behavior

When an agent generates a screenshot using a supported browser workflow, the runtime should allow the full workflow to succeed:

1. launch browser
2. render target page
3. write screenshot file to a stable accessible path
4. verify the file exists
5. allow the image to be read/attached/sent back to the user

Actual behavior

The browser can partially execute, but the screenshot artifact is not reliably available afterward.

As a result, screenshot requests fail at the final delivery step even though rendering appears to have happened.

Why this matters

This blocks important agent workflows such as:

• taking product screenshots for users
• capturing landing pages for review
• creating visual references for marketing work
• comparing UI states across builds
• generating screenshots for bug reports and documentation

A screenshot workflow that renders but cannot deliver output is effectively broken for end users.

Possible root cause areas

Potential areas worth investigating:

• sandbox/runtime restrictions around browser file output
• path permission mismatches between workspace and browser runtime
• temporary filesystem isolation or cleanup behavior
• Snap Chromium confinement behavior
• artifact handoff between browser execution and FoxFang file tools
• attachment/delivery support for runtime-generated image files

Requested fix

Make screenshot/browser output reliably usable inside FoxFang by ensuring that agents can:

• generate screenshots to a writable path
• verify those files exist afterward
• read the files through normal tools
• attach or deliver the images back to users

Acceptance criteria

• a headless browser can generate a screenshot in FoxFang without path or permission failure
• the generated file remains accessible after command completion
• the file can be read or attached through the normal runtime toolchain
• agents can successfully send the resulting screenshot back to the user
• documentation reflects the supported screenshot path and workflow

Context

This issue comes from a real request to take a screenshot of https://reply.cash and send it to the user from within FoxFang. Rendering partially worked, but file output and delivery did not complete successfully.