Summary

agent-browser 0.24.0 with -p agentcore appears to create AgentCore browser sessions successfully, but open often fails with:

Invalid response: EOF while parsing a value at line 1 column 0
(after 5 retries - daemon may be busy or unresponsive)

When this happens, the browser remains at about:blank, and multiple orphaned READY AgentCore sessions are left behind in AWS.

This reproduces with both:

• AGENTCORE_PROFILE_ID set
• AGENTCORE_PROFILE_ID unset

So this does not appear to be specific to persisted profiles or to x.com.

Environment

• agent-browser: 0.24.0
• Install method: npm install -g agent-browser
• OS: macOS (Darwin arm64)
• Provider: agentcore
• Region: us-east-1
• Browser identifier: aws.browser.v1

Reproduction

agent-browser close --all
agent-browser --session acore-test -p agentcore open "https://example.com"

Also reproduced with:

agent-browser --session acore-test -p agentcore open "https://x.com/home"

And also reproduced with profile persistence disabled:

env -u AGENTCORE_PROFILE_ID agent-browser --session acore-test -p agentcore open "https://example.com"

Actual behavior

• open fails with EOF / daemon-unresponsive error
• get url returns about:blank
• get title is empty
• AWS AgentCore accumulates multiple READY browser sessions from a single failing test flow
• those sessions need manual cleanup via aws bedrock-agentcore stop-browser-session

Example follow-up commands after failure:

agent-browser --session acore-test -p agentcore get url
# about:blank

agent-browser --session acore-test -p agentcore get title
# empty

Expected behavior

• open should either navigate successfully, or fail cleanly without spawning multiple orphaned AgentCore sessions
• failed runs should not leave many remote READY sessions behind

Notes

A clean reinstall did not fix this:

npm uninstall -g agent-browser
npm install -g agent-browser

The issue still reproduced immediately afterward with https://example.com.

Daemon logs suggest that remote AgentCore sessions are being created successfully (session ID + Live View URL are printed), so the failure seems to happen after session creation, likely somewhere in the daemon/provider/session lifecycle or CLI<->daemon response path.