[Feature]: Explicit Windows shell selection and ACP effective-shell reporting #474

Request

Please expose an explicit process-local shell selection option for MiniMax Code's own command tools on Windows, and report the resolved interpreter to ACP clients. Git Bash should be selectable while leaving the current PowerShell default unchanged.

Motivation and observed behavior

We integrate the official mcode ACP harness into OPL DSH. On Windows, our tested official mcode v0.6.3 resolves PowerShell even when Git for Windows is installed and SHELL points to Bash. A tool named bash, or a model explicitly wrapping bash.exe, does not establish that the harness's actual default command interpreter is Bash.

The public shared resolver at third_party/pi-mono/packages/coding-agent/src/utils/shell.ts already accepts a custom shell path; the current main still documents Windows PowerShell preference. The request is a supported way to apply an explicit choice consistently to mcode's own foreground/background operations and expose the result. We have not runtime-tested every newer release.

Suggested interface (names are proposals)

• An explicit shell executable setting or process-local environment variable, such as MCODE_SHELL_PATH.
• Validate an absolute existing executable; an invalid explicit selection fails with a useful error rather than falling back to another interpreter.
• Use the same resolved shell for foreground/background commands and the model's environment description.
• Optional ACP initialize metadata, for example:

{"_meta":{"minimax-code/shell":{"version":1,"type":"bash","executable":"C:/Program Files/Git/bin/bash.exe","args":["-c"]}}}

The exact setting name, metadata placement, and versioning should follow the maintainers' preferred public API. Clients should be able to verify the effective shell across reconnects; older clients can ignore the optional metadata.

Existing prototype and validation

We have a small local source patch against official v0.6.3, built as a separately selected candidate; it does not replace the official installation. Windows validation covered an executable path containing spaces, real Bash identity/output and nonzero exit status, stdout/stderr streaming, cancellation/timeout cleanup, ACP capability readback, and model-backed command execution with both M3.1-Flash-Preview and M3, including cross-process session recovery. These are observations from the local prototype, not claims about official release support or the entire test suite.

The source patch can be adapted and contributed if maintainers approve the direction. We are opening an issue first in accordance with CONTRIBUTING.md's collaborator-only PR policy. The consuming integration and its explicit support limitations are documented in gaofeng21cn/opl-dsh#6 and https://github.com/gaofeng21cn/opl-dsh/blob/main/docs/minimax-code.md.

Scope

This selects and reports a command interpreter only. It must not change permission modes, approve pending human requests, weaken sandbox enforcement, or silently upgrade restricted tasks to full access. It does not require an OPL-specific agent loop or any MiniMax account/provider changes.

Would maintainers prefer a CLI/config setting or an environment override, and what ACP capability-reporting interface would fit the project?