Expose executor OS and architecture in `environment/info` and model context

Feature request: Expose executor OS and architecture in environment/info and model context

Codex variant: CLI / app-server / exec-server, especially remote environments

Feature request

Please add os and arch to the environment/info response, forward them through the app-server v2 environment/info API, and include them in the environment fragment sent to the model.

The fields should use a compact, stable format:

{
  "shell": {
    "name": "powershell",
    "path": "powershell.exe"
  },
  "cwd": "file:///C:/workspace",
  "os": "windows",
  "arch": "x86_64"
}

Suggested values:

• os: windows, macos, or linux
• arch: the executor process ABI, for example x86_64 or aarch64

Contribution request

I would be happy to prepare a focused implementation and the associated tests if maintainers agree with this direction. In accordance with the contribution guidelines, please explicitly invite a pull request if you would like me to make this change; I will not open an unsolicited PR.

Current behavior and root cause

environment/info currently exposes only shell and cwd. The app-server v2 environment/info response has the same limitation.

In core, the model-visible environment state receives only the shell name and renders only cwd, optional status, and shell. There is therefore no os or arch value available to render.

The relevant model-context fragment currently looks like this (outer context wrappers omitted):

<environment id="windows-1">
  <cwd>C:\workspace</cwd>
  <shell>powershell</shell>
</environment>

This is not a case where os and arch exist upstream but are accidentally omitted during rendering: they are absent from the EnvironmentInfo protocol type and are never propagated into TurnEnvironment.

Why environment_id, shell, and cwd are insufficient

environment_id is an opaque identifier. Shell and cwd are not reliable platform identifiers.

For example, these two execution environments can report identical visible metadata:

{
  "environment_id": "default",
  "shell": { "name": "zsh", "path": "/bin/zsh" },
  "cwd": "file:///workspace"
}

One can be macOS and the other Linux. The model cannot safely infer package-manager commands, path behavior, platform-specific build tooling, or executable compatibility. arch additionally matters for native dependencies, release artifacts, emulation, and cross-compilation.

This is especially important when the UI/client and exec-server run on different hosts or operating systems.

Expected model context

For the earlier Windows example, the model should receive:

<environment id="windows-1">
  <cwd>C:\workspace</cwd>
  <shell>powershell</shell>
  <os>windows</os>
  <arch>x86_64</arch>
</environment>

The fields should follow the existing environment-context diff behavior: include them in the initial environment state and resend them only if they change.

Proposed implementation

1. Extend exec-server-protocol EnvironmentInfo with os and arch.
2. Populate local values in EnvironmentInfo::local() from the executor process platform, without shelling out or adding a dependency.
3. Forward the fields through app-server v2 environment/info.
4. Preserve them in TurnEnvironment, EnvironmentState, and environment snapshots.
5. Render <os> and <arch> beside the existing environment metadata.
6. Regenerate the app-server schema and update the app-server API documentation.

Compatibility and semantics

For exec-server protocol compatibility, the new fields should deserialize as optional/defaulted values. A new client must still be able to connect to an older remote exec-server that returns only shell and cwd; in that case core should simply omit <os> and <arch> from context.

A current exec-server should always return both fields.

arch should mean the architecture/ABI of the execution environment as reported by the exec-server process, not necessarily the physical host CPU. This makes the value actionable for command execution. For example, a WSL executor should report os: "linux" because Unix command and path semantics apply there; detecting WSL, Linux distribution, kernel version, hostname, or environment variables is out of scope.

Feasibility report

This appears to be a small, low-risk additive change:

• EnvironmentInfo::local() is already the centralized place that constructs local executor metadata.
• The protocol and app-server response already provide the environment-info call path.
• The existing environment-context struct already implements a bounded context-fragment mechanism; two short strings do not create an unbounded or large context item.
• The main implementation risk is backward compatibility with older remote exec-servers, addressed by optional/defaulted deserialization.
• No filesystem probing, shell command, platform-specific process invocation, or new dependency should be required.

Suggested coverage:

1. Protocol compatibility: a legacy environment/info response without os/arch still deserializes.
2. app-server v2: environment/info forwards both values from a remote executor.
3. Core integration: a remote environment produces the expected <os> and <arch> model-context elements, including incremental context updates.

Please consider implementing this so model decisions consistently use the executor's actual OS and architecture rather than inferring them from shell and path heuristics.