docs: codex --browser-mcp clarifications; USER_VOLUMES debug guard

deva.sh

@@ -3518,7 +3518,7 @@ mask_secrets_in_args() {
 if [ "$DEBUG_MODE" = true ]; then
     echo "=== DEBUG: Docker command ===" >&2
     echo "Container name: $CONTAINER_NAME" >&2
-    echo "USER_VOLUMES (${#USER_VOLUMES[@]}): ${USER_VOLUMES[*]}" >&2
+    echo "USER_VOLUMES (${#USER_VOLUMES[@]}): ${USER_VOLUMES[*]-}" >&2
     echo "Ephemeral mode: $EPHEMERAL_MODE" >&2
     echo "" >&2
     if [ "$EPHEMERAL_MODE" = false ]; then

docs/how-it-works.md

@@ -149,10 +149,15 @@ This is not subtle. The container is the trust boundary, so the agent's internal
 ## Browser Wiring
 
 - `deva.sh claude -- --chrome` is Claude's host Chrome bridge. deva mounts the host bridge dir and wires the container tmp path Claude expects.
-- `deva.sh codex --browser-mcp` is Codex MCP wiring. deva injects a session-only `mcp_servers.playwright` override and uses the rust image profile.
+- `deva.sh codex --browser-mcp` is Codex MCP wiring. deva injects a session-only `mcp_servers.playwright` override, uses the rust image profile, and runs an isolated Chromium from inside the container.
 
 Do not treat these as interchangeable. Codex CLI does not consume Claude's `--chrome` bridge, and Claude's native `--chrome` mode does not read Codex MCP config.
 
+The Codex desktop Chrome plugin is also not a mount target for the Linux
+container. It depends on host Codex app resources, a host native messaging
+manifest, and the installed Chrome extension. Mounting those macOS paths into
+the container does not make them executable there.
+
 ## Proxy and Network Behavior
 
 - `HTTP_PROXY` and `HTTPS_PROXY` are passed through

docs/troubleshooting.md

@@ -181,10 +181,18 @@ What deva does:
 
 - switches the default image profile to `rust`, where browser runtime dependencies live
 - injects a session-only Codex MCP override for `mcp_servers.playwright`
+- uses an isolated in-container Chromium, not the host Chrome profile
 - leaves your host `~/.codex/config.toml` untouched
 
 The injected MCP command uses `npx -y`, so the first run may fetch `DEVA_CODEX_BROWSER_MCP_PACKAGE` unless it is already cached in the container.
 
+Do not try to make this work by mounting the Codex desktop Chrome plugin into
+the container. On macOS that plugin points at host-only paths such as
+`/Applications/Codex.app`, `~/.codex/plugins/cache/openai-bundled/chrome`, the
+Chrome native messaging manifest, and a platform-specific extension host
+binary. Those are part of the host app and extension bridge, not a portable
+Linux container browser runtime.
+
 Check:
 
 ```bash
@@ -215,6 +223,7 @@ If Codex also tries to start host-specific or unrelated MCP servers, add session
 CODEX_BROWSER_MCP=true
 CODEX_CONFIG=features.apps=false
 CODEX_CONFIG=features.plugins=false
+CODEX_CONFIG=mcp_servers.node_repl.enabled=false
 CODEX_CONFIG=mcp_servers.hn-research={url="https://hn.1lm.io/mcp",enabled=false}
 ```