Windows: sandbox silently denies access outside workspace; no elevation prompt; PowerShell/Git Bash inconsistency; auto-compaction never triggers on small context windows

[coyn1983]

正文结构：

环境：Windows + DSH v0.2 + Ollama 0.34.4 + 本地 Qwen3.5-9B（32k ctx，workspace-write 模式）
Bug 1-5：逐条写“现象 → 复现步骤 → 期望行为”，今天每条都有现成的复现过程
Bug 6（最硬的一条）​：32.8K 窗口下自动压缩公式 min(W×0.8, W−O−65536) 算出负触发点，实测会话跑到 99.1%（32.5K/32.8K，剩余 314 token）压缩从未发生，最终上下文窒息导致模型幻觉和停摆——附上统计面板数据
结尾附一句 Git Bash 能读 E 盘 142 个文件而 PowerShell 工具返回空的对照证据

AI叫我发的，我小白，仅供参考

[argszero]

Bug 6 first, because the arithmetic is checkable and the answer changes what to do about it — then the sandbox items as one class, since they look like five symptoms of two causes.

Bug 6: on a 32.8K window the pressure trigger is not "not reached yet", it is unreachable by construction

Your outline reads the formula as min(W×0.8, W−O−65536) producing a negative trigger point that is simply never met. The effect is right; the mechanism is one step sharper, and the sharper version tells you which knob to turn.

packages/compaction/compaction-basic/src/config.ts (lines 172-191):

const messageBudgetTokens  = contextWindow - reservedCompletionTokens
const pressureBudgetTokens = messageBudgetTokens - policy.headroomTokens
if (pressureBudgetTokens <= 0) throw new TargetPressureConfigError(...)      // line 182
const thresholdTokens = Math.floor(Math.min(
  contextWindow * policy.thresholdRatio,      // the W × 0.8 term
  pressureBudgetTokens,                       // the W − O − headroom term
))

With W = 32800 and the default headroomTokens = 65536, pressureBudgetTokens is negative before any comparison happens, so the branch does not evaluate a threshold at all — it throws TargetPressureConfigError, and the message names the arithmetic:

compaction-basic: <provider>/<model> reserves N completion tokens and 65536 headroom tokens of its 32800-token context window, leaving no pressure budget; reduce the effective request maxTokens or compaction headroomTokens, or configure a larger adapter model contextWindow

So the reason compaction never fired is that the feature has no budget left to act in. The 65536 default (compaction-basic/README.md, headroomTokens) is a fixed absolute number chosen for windows many times larger than 32.8K; on your model it is twice the whole window.

Three things follow, all of them configuration rather than a bug in the formula:

• Set headroomTokens proportionally — a few thousand for a 32.8K window is the intent of the knob.
• reservedCompletionTokens is charged against the same window (src/index.ts:65-67: the effective request's maxTokens, else the adapter's per-request default), so the request cap and the window have to leave room for each other. If the two together exceed W, nothing can help until one shrinks.
• The adapter model's declared contextWindow must be the real one. If it is declared larger than the model actually serves, the estimate is confident about a capacity that does not exist — which is why the threshold can look satisfied while the provider still truncates.

One practical note for the workflow you were probably in: the pressure trigger runs at the step boundary, so it needs a step to end before it can look. A single very long tool-heavy step can pass the threshold and keep going until that step completes.

The sandbox items (1-5, plus the shell asymmetry) are one class we have been collecting for a while

Your five observations are the discriminators, not five separate bugs, and they have quite different remedies:

• Denial outside the workspace, no prompt. By design this is a configured boundary, not a per-call grant: sandbox-policy/src/index.ts:47 states workspace-write as "may modify files under the session workspace"; line 49 states danger-full-access as no restriction. What a denial does return is a model-facing [sandbox: …] marker plus an escalation hint (tool-fs/src/sandbox.ts:126-129), so "nothing appeared" usually means the hint reached the model and the model did not act on it, rather than the harness staying silent.
• workspace-write is exactly "in this workspace, and platform temp areas" — an E: drive root, a sibling project directory or a user profile path outside the session cwd is outside, no matter how harmless the command. A read-only command fails identically: the failure belongs to the workspace, not to what the command does, which is what makes "try something harmless first" a non-retry.
• Git Bash reading 142 files while the PowerShell tool returns nothing is a discriminator, not a contradiction: the two resolve the path through different mechanisms, and under a restricted token the ACL check can refuse the native process while a translation layer still reads. Which half refuses changes the remedy.

This is the family we ship @argszero/cordis-plugin-sandbox-grant-advisor for (npm, currently 0.14.0; source discussions #423, #8193, #8208, #8232, #8272, #8336, #8383, #8409). It reports which of the distinct causes you have rather than naming the symptom, because the remedies differ:

• entitlement half vs label half — one directory can be persistently denied for one security principal while its subdirectories stay writable (and the reverse), and re-granting the ACE does not fix the label case;
• "the root itself is refused" — the grant was materialized once per provider lifetime into an in-memory map, so after a restart/reload nothing has been granted: the remedy is restarting the provider, not re-running the command;
• workspace-internal denial — the failure belongs to the workspace, not to the command, so the working remedy is the workspace root, not a different command;
• shell asymmetry — the two-mechanism discriminator above.

It is a diagnostic tool, not a sandbox patch: it changes no permission and no sandbox behaviour. If you can attach the denial text you actually got (the [sandbox: …] marker, or the raw error from the tool result) for one of the five, that is enough to say which of the four families you are in — and if this is on a Desktop build, note the version, because the ACL remediation changed shape between 0.1.7 and 0.2.0.