feat(api): read and write a workspace's project trust over the Runtime API

[gaord]

What and why

Everything the engine skips for an untrusted workspace is silent, and the only
way to settle it was a terminal and /trust on --save. A client that is not the
TUI — the VS Code extension I am building against this API — had no way to see
the verdict or record it, so a user could sit in front of a project whose
trust-sensitive skills, commands, hooks and MCP configuration were quietly not
loading, with nothing in the UI to act on.

• GET /v1/workspace/status now reports workspace_trusted next to the git
  facts it already carried.
• POST /v1/workspace/trust with {"trusted": true|false} records the
  decision.

The route is deliberately the only writer a client gets. It calls
config::set_workspace_trust, the same function behind /trust on --save, so
both front ends write the one [projects."<workspace>"] trust_level record that
is_workspace_trusted — the gate the engine actually consults — reads back. A
client never edits config.toml: the file is the user's, and a second writer
would be a second source of truth for a security decision.

Three details worth a reviewer's attention:

• The workspace is the server's own (state.workspace). The route accepts no
  path, so a client can trust the project it is attached to and nothing else.
• The response's workspace_trusted is read back through the gate after the
  write rather than echoing the request. If a write ever landed somewhere
  is_workspace_trusted does not look, the response reports false instead of
  claiming success, and config_path names the document that now holds it.
• The effect is not retroactive, and the message says so instead of implying
  otherwise: skills and commands consult the persisted decision at their
  existing boundaries; project hooks also need exact-file digest approval,
  and project MCP connections are rebuilt at the next engine start. Project
  instructions and existing MCP connections are not removed by this POST.

/trust add <path> (the external-path list in workspace_trust.rs) is a
different mechanism and is untouched, as is a thread's trust_mode / Full
Access — the docs now spell out which is which.

Issue

No-Issue: no tracking issue; this is the engine half of a client-side gap found while building the VS Code extension against the Runtime API.

Contributor-reported original local verification

cargo fmt --all -- --check
cargo clippy -p codewhale-tui --all-targets --all-features --locked -- \
  -D warnings -A clippy::uninlined_format_args -A clippy::too_many_arguments \
  -A clippy::unnecessary_map_or -A clippy::collapsible_if -A clippy::assertions_on_constants
RUST_MIN_STACK=8388608 cargo test -p codewhale-tui --lib -- runtime_api::   # 456 passed
cargo test -p codewhale-tui --test feature_registry                        # 2 passed

Three new tests in runtime_api::tests, against the real router (they run the
product stack like their neighbours):

• workspace_trust_is_reported_and_written_through_the_api — the round trip in
  both directions, that the response names the server's own workspace, and that
  the named document really carries
  projects."<workspace>".trust_level = "trusted" / "untrusted".
• workspace_trust_route_refuses_malformed_bodies — a missing field and an
  unknown field are both 422, and the document is byte-identical afterwards.
  deny_unknown_fields is load-bearing here: a permissive parse would default
  trusted to false and silently revoke the workspace.
• workspace_bootstrap_status_reports_the_trust_gate — sealed, on one thread:
  the status projection follows the gate, up and back down.

The first version of the HTTP tests was wrong, and CI caught what a laptop
could not. They asserted the write through a second request and failed on
Test (ubuntu-latest) while passing locally. The cause is in the test harness,
not the route, and it is worth writing down because it is easy to rediscover the
hard way:

• unsealed_test_state_root() returns a root keyed by the resolving thread's
  id (env-holder-ThreadId(N)/config.toml), and with_test_state_path counts as
  a holder while it resolves — so any thread that resolves the user config gets
  its own test config document. Two requests served by different blocking workers
  therefore legitimately read and write two different files. On my machine both
  spawn_blocking calls landed on one pooled worker; on CI they did not. I
  confirmed the mechanism with a throwaway probe before changing anything.
• Sealing the home instead deadlocks: the route resolves its config on a
  spawn_blocking worker, which is not a member of the test's env scope, so it
  blocks on lock_test_env while the sealing test waits on the server. libtest
  has no per-test timeout, so the binary hangs rather than failing.

So the HTTP tests now assert only what one request can prove on its own — and
that is the stronger half anyway, since the read-back happens inside that
request — and the cross-request property moved to the sealed, single-threaded
test where it is deterministic. Re-ran the three 25× plus 12× under
--test-threads=8 with no failures.

Running these locally needs RUST_MIN_STACK (CI sets 8 MiB), otherwise an
unrelated debug-build stack overflow aborts the suite before they run.

Known limitation (not addressed here)

The route resolves the config path through config::set_workspace_trust /
is_workspace_trusted, which use the default discovery path — not the
--config a runtime may have been launched with. A server started with
--config /custom/config.toml therefore records trust in the default document.
That is exactly what the TUI's /trust on --save does, so read, write and gate
all agree; making the gate honour a per-runtime override would mean threading a
path through its ~15 call sites, which is a separate change. Flagging it rather
than fixing it half-way, which would be worse: a writer honouring --config
with a gate reading the default path is precisely the disagreement the response's
read-back exists to refuse. The consuming extension launches the engine without
--config, so it is not affected today.

Current maintainer correction and gate

The original contribution and its three tests remain. Current main was merged into the original branch without rewriting history. 10d047c1 corrected both API messages and owning English/Chinese docs to actual trust/context/hook/config boundaries. Default-config discovery remains explicit; project trust does not alter Full Access or external-path grants.

Two maintainer integration errors were then corrected: 3a1eae9f keeps the existing feature summary within its120-character contract; 97aac3e regenerates its documentation and feature projections with the existing generator. The earlier Ubuntu registry failure and stale-generated-doc web failure remain recorded.

Current exact-head Web38496306483 passed772Vitest tests, facts/docs validation and build. Native CI38496306482 completed: macOS19,038/0failed/33skipped, Ubuntu19,035/0/34, Windows18,304passed(oneleaky)/0/27 and Lint. All three trust cases and owner recovery passed on every platform; unique full-suite ordinals and exact source were independently checked. Web772Vitest/facts/docs/build passed. No live authorization or final packaged acceptance is claimed. The source branch/original authored commits and tests remain. This PR merged as itself at 947f670fee. Original author commits, three tests and branch are preserved. It is now on main, but not yet folded into the ECD release branch. No release publication or issue closure.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[Hmbown]

Thank you @gaord for making workspace trust inspectable and writable by non-TUI clients through the engine’s existing config authority, and for the three tests covering round-trip, malformed bodies and bootstrap projection. Your #6959 merged as its own PR at 947f670fee, preserving your commit, tests and branch. Exact own-head CI passed: macOS19,038/0failed/33skipped, Ubuntu19,035/0/34, Windows18,304passed(oneleaky)/0/27 and Lint; all three trust cases and owner recovery passed everywhere. Web772Vitest/facts/docs/build passed. The API response and docs keep the separate hook-digest approval, default-config and MCP-restart limits explicit. This is on main for the 0.10.2 candidate; final assembled-source and package acceptance still remain.

[Hmbown]

What and why

Everything the engine skips for an untrusted workspace is silent, and the only
way to settle it was a terminal and /trust on --save. A client that is not the
TUI — the VS Code extension I am building against this API — had no way to see
the verdict or record it, so a user could sit in front of a project whose
trust-sensitive skills, commands, hooks and MCP configuration were quietly not
loading, with nothing in the UI to act on.

• GET /v1/workspace/status now reports workspace_trusted next to the git
  facts it already carried.
• POST /v1/workspace/trust with {"trusted": true|false} records the
  decision.

The route is deliberately the only writer a client gets. It calls
config::set_workspace_trust, the same function behind /trust on --save, so
both front ends write the one [projects."<workspace>"] trust_level record that
is_workspace_trusted — the gate the engine actually consults — reads back. A
client never edits config.toml: the file is the user's, and a second writer
would be a second source of truth for a security decision.

Three details worth a reviewer's attention:

• The workspace is the server's own (state.workspace). The route accepts no
  path, so a client can trust the project it is attached to and nothing else.
• The response's workspace_trusted is read back through the gate after the
  write rather than echoing the request. If a write ever landed somewhere
  is_workspace_trusted does not look, the response reports false instead of
  claiming success, and config_path names the document that now holds it.
• The effect is not retroactive, and the message says so instead of implying
  otherwise: skills and commands consult the persisted decision at their
  existing boundaries; project hooks also need exact-file digest approval,
  and project MCP connections are rebuilt at the next engine start. Project
  instructions and existing MCP connections are not removed by this POST.

/trust add <path> (the external-path list in workspace_trust.rs) is a
different mechanism and is untouched, as is a thread's trust_mode / Full
Access — the docs now spell out which is which.

Issue

No-Issue: no tracking issue; this is the engine half of a client-side gap found while building the VS Code extension against the Runtime API.

Contributor-reported original local verification

cargo fmt --all -- --check
cargo clippy -p codewhale-tui --all-targets --all-features --locked -- \
  -D warnings -A clippy::uninlined_format_args -A clippy::too_many_arguments \
  -A clippy::unnecessary_map_or -A clippy::collapsible_if -A clippy::assertions_on_constants
RUST_MIN_STACK=8388608 cargo test -p codewhale-tui --lib -- runtime_api::   # 456 passed
cargo test -p codewhale-tui --test feature_registry                        # 2 passed

Three new tests in runtime_api::tests, against the real router (they run the
product stack like their neighbours):

• workspace_trust_is_reported_and_written_through_the_api — the round trip in
  both directions, that the response names the server's own workspace, and that
  the named document really carries
  projects."<workspace>".trust_level = "trusted" / "untrusted".
• workspace_trust_route_refuses_malformed_bodies — a missing field and an
  unknown field are both 422, and the document is byte-identical afterwards.
  deny_unknown_fields is load-bearing here: a permissive parse would default
  trusted to false and silently revoke the workspace.
• workspace_bootstrap_status_reports_the_trust_gate — sealed, on one thread:
  the status projection follows the gate, up and back down.

The first version of the HTTP tests was wrong, and CI caught what a laptop
could not. They asserted the write through a second request and failed on
Test (ubuntu-latest) while passing locally. The cause is in the test harness,
not the route, and it is worth writing down because it is easy to rediscover the
hard way:

• unsealed_test_state_root() returns a root keyed by the resolving thread's
  id (env-holder-ThreadId(N)/config.toml), and with_test_state_path counts as
  a holder while it resolves — so any thread that resolves the user config gets
  its own test config document. Two requests served by different blocking workers
  therefore legitimately read and write two different files. On my machine both
  spawn_blocking calls landed on one pooled worker; on CI they did not. I
  confirmed the mechanism with a throwaway probe before changing anything.
• Sealing the home instead deadlocks: the route resolves its config on a
  spawn_blocking worker, which is not a member of the test's env scope, so it
  blocks on lock_test_env while the sealing test waits on the server. libtest
  has no per-test timeout, so the binary hangs rather than failing.

So the HTTP tests now assert only what one request can prove on its own — and
that is the stronger half anyway, since the read-back happens inside that
request — and the cross-request property moved to the sealed, single-threaded
test where it is deterministic. Re-ran the three 25× plus 12× under
--test-threads=8 with no failures.

Running these locally needs RUST_MIN_STACK (CI sets 8 MiB), otherwise an
unrelated debug-build stack overflow aborts the suite before they run.

Known limitation (not addressed here)

The route resolves the config path through config::set_workspace_trust /
is_workspace_trusted, which use the default discovery path — not the
--config a runtime may have been launched with. A server started with
--config /custom/config.toml therefore records trust in the default document.
That is exactly what the TUI's /trust on --save does, so read, write and gate
all agree; making the gate honour a per-runtime override would mean threading a
path through its ~15 call sites, which is a separate change. Flagging it rather
than fixing it half-way, which would be worse: a writer honouring --config
with a gate reading the default path is precisely the disagreement the response's
read-back exists to refuse. The consuming extension launches the engine without
--config, so it is not affected today.

Current maintainer correction and gate

The original contribution and its three tests remain. Current main was merged into the original branch without rewriting history. 10d047c1 corrected both API messages and owning English/Chinese docs to actual trust/context/hook/config boundaries. Default-config discovery remains explicit; project trust does not alter Full Access or external-path grants.

Two maintainer integration errors were then corrected: 3a1eae9f keeps the existing feature summary within its120-character contract; 97aac3e regenerates its documentation and feature projections with the existing generator. The earlier Ubuntu registry failure and stale-generated-doc web failure remain recorded.

Current exact-head Web38496306483 passed772Vitest tests, facts/docs validation and build. Native CI38496306482 is still pending; no full CI, live authorization or packaged acceptance is claimed. The source branch/original authored commits and tests remain. This PR is not yet merged or included inECD; no release publication or issue closure.

Thank you so much!!!