Codex in-app browser fails because node_repl rejects node:process

- [x] I searched open and closed issues for duplicates.
- [x] I reproduced this on the latest release.
- [x] This is one bug, not several bundled together.

## Closest existing issue

#98 is the nearest browser-related issue, but it requests a human-visible embedded page panel. This report concerns an existing Codex browser tool failing during execution, so it does not appear to be a duplicate.

## What's broken

In new Codex sessions, attempting to open a public webpage with the in-app browser fails inside `mcp__node_repl__js`. Native search works, but the browser cannot open the destination page.

## Steps to reproduce

1. Launch Berd v0.6.2 on Apple Silicon macOS.
2. Open a project with a local folder attached.
3. Start a new session with:
- Harness: Codex
- Model: `gpt-5.6-luna`
- Prior chat history: none
4. Ask the agent:

> Use the in-app browser—not web search—to open https://www.historics.co.uk/ and report its page title. Do not use search, shell commands, scripts, APIs or another fallback.

5. The session invokes `mcp__node_repl__js`.
6. The browser does not open the page.
7. Repeat in another new session with `https://www.cnn.com/`.

## What I expected to happen

The in-app browser should open the public webpage and return its page title, or return an actionable browser-initialisation error.

## What actually happened

No tested page opened and no page title was available.

The primary error, reproduced in separate sessions and against both Historics and CNN, was:

```text
Importing module "node:process" is not allowed in node_repl
```

One intermediate attempt returned:

```text
browserType.connectOverCDP: connect ECONNREFUSED 127.0.0.1:9222
```

I then launched a separate Chrome profile with remote debugging bound to localhost. `lsof` confirmed Chrome listening on `127.0.0.1:9222`, but the next clean CNN test again failed earlier with the `node:process` error.

Browser tool invoked:

```text
mcp__node_repl__js
```

## How often does it happen?

Every time — reproducible across multiple new sessions. The exact failure alternated once, but no page opened successfully.

## Berd version

0.6.2

## Operating system

macOS 26.5.2, Apple Silicon

## Model and provider

Codex harness, model `gpt-5.6-luna`, authenticated through an OpenAI/ChatGPT subscription.

## Relevant log output

No relevant occurrence of `node:process`, `node_repl`, `ECONNREFUSED`, or `9222` was found in:

```text
~/Library/Logs/xyz.block.berd/berd.log
```

The exact errors were displayed in the sessions themselves.

## Additional environment context

The installed managed packages report:

```text
@agentclientprotocol/codex-acp 1.4.0
@openai/codex 0.147.0
ChatGPT macOS app 26.814.41957
Google Chrome 151.0.7922.138
```

Berd v0.6.2 installed its managed ACP bridge without a release-controlled version. PR #48, merged after v0.6.2, introduces release-controlled bridge installation and pins a different bridge version. This may be relevant version-skew context, but I have not established that it caused the browser failure.

No project files were changed by the failed browser attempts.

Start at the mcp__node_repl__js browser entry point and compare the managed ACP bridge versions before and after PR #48. Reproduce with the listed public URLs and inspect ~/Library/Logs/xyz.block.berd/berd.log alongside the session errors. Done means the browser opens the page and returns its title, or reports an actionable initialization error.

Written by the indexing model from the issue text.