[exec-server] Make missing environment/info failures explicit and observable

Summary

Third-party Codex exec-server bridges can currently fail an explicit-shell command before process/start when they do not implement environment/info. The user-visible error is only:

environment <id> does not report a shell

In an embedded host integration, that pre-dispatch attempt may be absent from the host's retained tool trajectory even though it is present in the Codex rollout. This makes the failure look like a model produced no tool call and encourages accidental model-retry dependence.

This report requests clearer protocol diagnostics/compatibility guidance and first-class observability for this failure class. It is not asking Codex to accept an invalid environment response.

Related OpenClaw bridge bug: https://github.com/openclaw/openclaw/issues/115575

Reproduction

1. Register an external exec-server environment.
2. Implement process and filesystem methods, but omit/reject environment/info.
3. Start a turn in that environment.
4. Emit:

{
  "cmd": "pwd",
  "shell": "bash",
  "login": false,
  "workdir": "/workspace"
}

Observed:

• Codex calls environment/info.
• The bridge rejects it.
• Codex returns environment <id> does not report a shell.
• No process/start is sent.
• A command encoded as bash -lc 'pwd' without the record-level shell field can still reach process/start, so model retry behavior changes the outcome.

PathUri integration trap

The current contract correctly returns cwd as a PathUri:

{
  "shell": { "name": "bash", "path": "/bin/bash" },
  "cwd": "file:///workspace"
}

One real third-party bridge treated that value as a native path and produced malformed probes such as:

/workspace/file:/workspace/.git
/workspace/file:/workspace/.agents/skills

The same integration also had multiple generated/vendored dispatcher bundles, so the apparent handler was not the importer-selected live handler. These are consumer bugs, but the combination makes protocol failures hard to diagnose.

Requested improvements

1. Document environment/info as mandatory for environments used by explicit-shell native tools, including the exact response shape and that cwd is a PathUri, not a native path string.
2. Include the rejected/missing method in the shell-resolution error, for example:

environment <id> does not report a shell: exec-server environment/info failed with method-not-found

1. Emit a structured pre-dispatch command failure event that embedded hosts can retain as a tool failure, even though process/start never occurred.
2. Add an integration fixture for an environment that omits environment/info, proving the failure is explicit and observable.
3. Consider exposing/caching environment info during initialization with backwards-compatible fallback, as explored in prior work, so incompatibility is detected before the first user command.

Why this matters

Without a structured retained failure, host-level metrics can report zero tool failures while Codex internally rejected an explicit-shell call. In the reproduced integration, a compatibility fix caused the first attempt to reach the sandbox and return complete stdout, but later soak gates still have to inspect both the host trajectory and Codex rollout to detect pre-dispatch regressions.