[Bug][Windows] read-only pwsh pollutes stderr with ConstrainedLanguage encoding errors

[ArmyWas]

Summary

On Windows, every pwsh command executed through the ACL sandbox in read-only mode inherits two PowerShell InvalidOperation records on stderr, even when the requested command succeeds with exit code 0.

中文摘要：Windows 只读沙箱会让 PowerShell 进入 ConstrainedLanguage；当前每条命令前无条件注入的 UTF-8 编码调用会失败两次，导致成功命令也携带两条无关 stderr。下面附有当前主分支上的根因、真实回归测试和已验证修复分支。

Reproduction and observed result

I found this while running authenticated app-CLI compatibility probes through a real DeepSeek Harness session. A controlled baseline that asked the read-only profile to run only node --version produced:

exit code: 0
stdout: v24.14.1
stderr (twice): InvalidOperation: Cannot create type. Only core types are supported in this language mode.

The same command in workspace-write mode has empty stderr. The Windows ACL end-to-end fixture also confirms that the read-only child is actually in ConstrainedLanguage.

Root cause

@deepseek-ai/dsh-pwsh-local prepends ENCODING_PREAMBLE to every command. The preamble unconditionally constructs System.Text.UTF8Encoding twice and assigns the console/output encodings. ConstrainedLanguage rejects those non-core static calls before the user command starts, so the bootstrap noise is indistinguishable from the command's own diagnostics.

The sandbox behavior itself is intentional and already documented. The narrower bug is the unconditional preamble inside that known restricted mode.

Tested fix

Guard the encoding assignments with an exact FullLanguage check. FullLanguage retains the existing UTF-8 pin; restricted modes keep the host encoding and avoid calls that cannot succeed.

A ready-to-review reference implementation is available here:

• Commit: ArmyWas@caec78d
• Branch: https://github.com/ArmyWas/deepseek-harness/tree/fix/pwsh-readonly-encoding-preamble

The patch adds a real Windows ACL regression assertion that proves all three facts together:

1. the child is in ConstrainedLanguage;
2. the requested read/write probes retain their existing behavior;
3. a successful read-only command now has empty stderr.

It also preserves the FullLanguage encoding behavior and updates the paired English/Chinese package documentation and Agent Note.

Validation

• Focused argv regression: 1 passed.
• Real Windows ACL end-to-end suite: 2 passed.
• Full repository lint/build: passed.
• Official pre-push typecheck (host build plus client TypeScript project): passed.
• Documentation quick gates: 15 passed, 0 failed.
• Corpus-wide translation pairing: 1,074 pairs consistent.

Local environment note: the broader suites contain two pre-existing symlink-creation fixtures that cannot run on this Windows host because Developer Mode is disabled (EPERM at symlinkSync). Their adjacent tests pass, and neither fixture touches this PowerShell change.

Per the current contribution policy, I am reporting the bug here instead of opening an external PR. I would be happy to adjust the patch if maintainers prefer a different guard or regression-test location.

[denial123789]

补充一份已发布的双语排查指南（v0.5.280）：\n\n- English: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/windows-readonly-pwsh-stderr.md\n- 中文: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/zh-CN/troubleshooting/windows-readonly-pwsh-stderr.md\n- Release: https://github.com/sandbaseai/deepseek-harness-handbook/releases/tag/v0.5.280\n\n指南把 exit code/stdout/stderr、ConstrainedLanguage、ACL 沙箱和 FullLanguage 编码 guard 拆成独立验收边界，并保留真实命令错误。手册是独立社区资料，不是官方插件或 API wrapper。

[argszero]

Independent verification of the report and the patch against alpha.1 (HEAD cd5ef81481) — both the root cause and the fix hold up at source.

Root cause confirmed (three facts, all in-tree)

1. packages/shell/pwsh-local/src/index.ts:48-49 — ENCODING_PREAMBLE unconditionally runs [Console]::OutputEncoding = [System.Text.UTF8Encoding]::new($false) and $OutputEncoding = ... twice per command.
2. :218 — the argv seam prepends it to every command: -Command "${ENCODING_PREAMBLE}${spec.command}". There is no language-mode branch anywhere in pwsh-local (grepped the whole package).
3. The internal inconsistency is real: packages/shell/tool-pwsh/src/index.ts:123-124 already documents that "read-only pwsh runs in PowerShell ConstrainedLanguage mode" — the sandbox's restricted mode is known to the tool layer, yet the preamble never accounted for it.

[System.Text.UTF8Encoding]::new() is a non-core type construction, so in ConstrainedLanguage both statements fail with InvalidOperation: Cannot create type. Only core types are supported in this language mode. — two deterministic stderr records per command, matching your byte-identical reproduction.

Patch review — correct, behavior-preserving, well-tested

• Guard expression: $ExecutionContext.SessionState.LanguageMode is the standard, documented way to read the session language mode and is available in -NoProfile -NonInteractive -Command contexts (automatic variable). The if form keeps the single-argv shape and preserves the "error line numbers stay accurate" property.
• Behavior preservation: in FullLanguage the two assignments still run — byte-identical output pinning. In restricted modes they are skipped, which is the only viable option: the assignment cannot succeed there, so there is no behavior to preserve.
• Acknowledged tradeoff: a hypothetical ConstrainedLanguage + Windows PowerShell 5.1 session could still emit non-UTF-8 bytes (5.1 writes the console code page by default; pwsh 7 defaults to UTF-8 and is unaffected, per the preamble's own doc comment). That is an acceptable residual — the encoding pin is impossible in that mode anyway, and the guard keeps the common read-only path clean.
• Tests: the executor.spec.ts assertion now pins the conditional and both assignments (guards against a future revert to unconditional), and the Windows ACL e2e regression asserting all three facts (ConstrainedLanguage child / probe behavior unchanged / empty stderr on success) is the right level of proof for a mode that jsdom and non-Windows CI cannot see.

This is the same class of bug as the pwsh family in #3911/#4239 (Windows pwsh execution-path edge cases that only surface under the sandbox), and the fix pattern (gate at the provider's argv seam, not at every call site) matches how the pwsh sandbox confinement is layered.

中文摘要：已在 alpha.1 源码逐一确认根因（pwsh-local:48-49 无条件注入 UTF-8 编码 pin + :218 每条命令前置；tool-pwsh:123-124 早已文档化只读沙箱为 ConstrainedLanguage，但 preamble 从未感知）——补丁用 $ExecutionContext.SessionState.LanguageMode -eq 'FullLanguage' 守卫，FullLanguage 行为逐字节不变，受限模式跳过必然失败的调用；测试覆盖（executor 断言条件化 + Windows ACL e2e 三事实）与补丁质量都到位，可以作为合并参考。

[ArmyWas]

@denial123789 and @argszero, thank you both.

The bilingual handbook usefully separates exit code, stdout/stderr, ConstrainedLanguage, and the encoding guard into independently checkable boundaries. The source-level review also materially strengthens this report: it confirms both the provider seam and why an exact FullLanguage guard preserves the existing unrestricted behavior.

I rechecked the current upstream master at dd6322d on 2026-09-01. pwsh-local still unconditionally prepends ENCODING_PREAMBLE, so this narrow issue remains present in the current source. The tested reference branch and commit in the original post remain available; I am keeping the proposed change limited to this verified stderr-pollution path.

No additional retest is expected from either of you. I appreciate the independent verification and the durable troubleshooting documentation.

中文摘要：感谢两位补充双语排查文档和源码级独立验证。今天复查当前 master（dd6322d）后，无条件注入编码前置逻辑仍然存在，因此这个窄问题目前仍有效；参考修复继续保持最小范围，不扩展到未经验证的行为。