Workspace Trust as an Agent-Harness Admission Boundary

Short answer

Workspace trust is an admission boundary, not a cosmetic warning. If an agent harness merges repository-owned configuration before it decides whether that repository is trusted, the repository can influence the very policy that is supposed to decide whether its state should be admitted.

Qwen Code PR #12198, merged on 19 September 2026 as c9839a94425bb0ae4409218173666b6350c21fb3, provides a useful current implementation example. When folder trust is enabled, an undecided workspace now starts untrusted in both the normal CLI and daemon fast-start path. Project settings, project .env files and project hooks stay disabled; privileged approval falls back to the default mode; and the shared core trust gate continues to withhold project rules, memory, skills, subagents, LSP and MCP integrations until the workspace is explicitly trusted.

This is Qwen host/runtime security behavior. It does not revise UHP, MCP, ACP or A2A wire semantics, does not establish native Qwen UHP adoption, and does not create a fresh HarnessRouter Qwen validation result.

Unknown must not collapse to trusted

A trust system has at least three meaningful workspace states when the feature is enabled:

Workspace state	Safe interpretation
Explicitly trusted	Workspace-owned configuration may be admitted according to normal policy.
Explicitly untrusted	Workspace-owned privileged configuration remains withheld.
No decision yet	Treat as untrusted until the user or governing policy makes a decision.

The third state is the dangerous one. Before #12198, an undecided workspace could inherit trusted defaults during startup. In a headless session there may be no trust dialog to correct that decision, so repository-provided startup hooks, environment state or a privileged approval mode could become effective without an explicit trust grant.

The reusable invariant is simple:

When trust enforcement is enabled, absence of a trust decision is not evidence of trust.

A boolean API that maps undefined to true destroys the security meaning of the undecided state. Agent hosts should preserve the distinction until a trusted authority resolves it.

Resolve trust before merging workspace policy

A workspace must not be able to disable the gate that decides whether workspace state is allowed to load. Qwen’s reviewed fix therefore resolves the trust policy from non-workspace scopes before project settings are merged. A project setting that attempts to disable folder trust no longer bypasses a user- or operator-enabled trust gate.

The ordering should be conceptualized as:

1. load trusted operator/user policy needed to decide whether workspace trust is enabled;
2. resolve the workspace’s trust decision;
3. if trust is absent or negative, construct the session without privileged workspace-owned state;
4. only after an explicit positive decision, load the workspace-owned settings and integrations permitted by policy.

This is broader than .qwen/settings.json. Repository-controlled hooks, environment files, model instructions, local memory, skills, subagents, LSP configuration and MCP servers can all change what the harness reads, executes, exposes to the model or connects to. They therefore belong on the protected side of the boundary when the host’s trust model says they are privileged.

Headless and daemon paths must agree with interactive startup

Security gates are easy to implement in a visible TUI and accidentally bypass in alternate startup paths. #12198 explicitly covers the normal CLI and the daemon fast-start loader so that an undecided workspace is not safe-mode in one path and implicitly trusted in another.

This matters for automation because a daemon, SDK host, CI job or headless agent often has less opportunity for a human trust prompt than the interactive client. A design that depends on the dialog itself as the security primitive will fail exactly where unattended execution is most common.

The authority should therefore live below the presentation layer. UI may collect the decision; loaders and runtime gates must enforce it independently.

Consent may require a clean reload

Withholding project configuration creates a second problem: after the user grants trust, previously skipped state has to be admitted in a controlled way. Qwen’s interactive trust flow restarts the CLI after a positive trust decision so project configuration is loaded only after consent. Declining trust continues without that restart.

That behavior encodes another useful boundary: do not partially mutate a running restricted session into a trusted one if the host cannot prove every previously withheld subsystem has been reloaded consistently. A clean restart or equivalently complete reinitialization is often safer than hot-enabling hooks, environment state, tool policy and integrations one subsystem at a time.

Approval mode belongs behind the trust gate

A repository-provided privileged approval mode is not merely configuration presentation; it can change whether tool operations require review. #12198’s before/after evidence shows an undecided workspace changing from yolo before the fix to default after it, while an explicitly trusted workspace still receives the project-selected mode.

The general rule is that trust classification must precede privilege escalation. If the workspace is not trusted, the harness should construct an effective policy from trusted scopes and use the safe/default approval behavior rather than inheriting a repository request for broader authority.

Trust scope and precedence are part of the security model

Qwen’s current trusted-folders documentation describes folder trust as disabled by default and stores explicit folder decisions centrally in ~/.qwen/trustedFolders.json. It also exposes distinct choices to trust the current folder, trust a parent, or mark a folder untrusted.

Parent trust is operationally convenient but expands the authorization surface: trusting a parent implicitly authorizes descendants under that rule. A trustworthy implementation therefore needs path-normalization and precedence rules that make explicit denials meaningful and avoid platform-specific path aliases changing the decision.

PR #12198 also records an operator/fleet case: when folder trust is enabled only through system-defaults.json, the initial check now includes that scope so startup admission and later trust gates agree. The important architectural point is that the source of the trust-enablement decision must be at least as trusted as the state it gates.

OpenTUI exposes an important product boundary

The reviewed change deliberately documents a UI gap. Qwen’s native OpenTUI renderer does not currently mount the three-option folder-trust prompt. Under that renderer an undecided workspace starts untrusted and cannot be trusted from inside the same run; project settings, project QWEN.md, workspace .env files and project MCP servers remain unloaded for that run.

Users can record the decision using the default Ink TUI and relaunch OpenTUI, or edit the central trusted-folders state through the supported mechanism. The important security choice is that the missing prompt does not become a reason to fail open.

This is a strong design pattern for agent clients: when a consent surface is unavailable, preserve the restricted state rather than manufacturing consent.

Protocol boundary

Workspace trust answers a host-local question: may this repository influence the agent runtime? MCP can describe servers and tools; ACP can connect a client and agent; UHP can front a harness runtime; A2A can coordinate agents. None of those wire protocols, by themselves, decides whether a local checkout is trusted to contribute hooks, environment files, approval policy or executable integrations.

A protocol-facing adapter may surface a trust rejection or restricted capability set, but the underlying authority remains a host security policy unless the protocol explicitly standardizes that trust model. Implementations should not relabel a local folder-trust decision as protocol conformance.

Verification boundary

The #12198 reviewer matrix covers undecided, project-attempted trust disablement, explicitly trusted, explicitly untrusted and user-disabled folder-trust states. Upstream reports 815 core configuration tests plus 959 CLI configuration, settings, daemon fast-path, trust-resolution, approval-mode and trust-dialog tests, with build and typecheck passing.

The source also states its limits: direct validation was on macOS with Node.js 22.22.3; native Windows and Linux runs were not locally tested; the OpenTUI native runtime was not validated as an interactive trust-grant path; and administrative extension/MCP subcommands using separate trust checks were outside the stated validation scope.

Treat those numbers as upstream implementation evidence, not cross-platform certification.

Practical review checklist

When reviewing workspace trust in an agent harness, verify:

1. Undecided is explicit: unknown trust cannot silently become trusted.
2. Policy precedes project merge: workspace state cannot disable the gate that controls workspace admission.
3. Headless parity: CLI, daemon, SDK and automation startup paths resolve the same effective trust state.
4. Privileged state is withheld: hooks, environment, local instructions, memory, skills, subagents, LSP, MCP and approval escalation are gated according to the product’s declared model.
5. Trusted scopes remain usable: user/system hooks and policy that are intentionally outside workspace ownership are not accidentally suppressed.
6. Grant transition is complete: post-consent loading uses a restart or an equivalently complete reinitialization boundary.
7. Missing UI fails closed: a client without a trust prompt stays restricted instead of assuming consent.
8. Scope is visible: trusting a folder versus a parent has clear, testable path semantics.
9. Operator policy participates: fleet/system defaults cannot disagree with the runtime gate because they were omitted from the initial decision.
10. Protocol claims stay narrow: local workspace trust is not described as MCP, ACP, A2A or UHP wire behavior without protocol evidence.

Primary sources

• Qwen Code PR #12198 — require explicit trust for undecided workspaces
• Qwen merge commit c9839a94
• Qwen Code trusted-folders documentation
• Qwen Code current-main trust precedence