E2E verification report

PASS on macOS, Node.js 22.14.0 and Java 21. The final run uses the packaged CLI, production Java Broker, separate Workspace workers, Spring HTTP Session Store and H2 in MySQL mode with Flyway. The model is a deterministic loopback OpenAI fixture; no real provider is involved.

The real integration runs file-only and Shell Sessions in six distinct Workspaces. It checks a Harness decoy, complete 100 MiB stdout (including invalid UTF-8 bytes), separate stderr, independently computed lengths/SHA-256/tails, the original Session/turn/execution identity and durable receipt admission before the next model request. The model sees an explicit bounded-preview notice and no recommendation to read an inaccessible worker output file. After the driver exits, the fixture captures the live producer processes, closes the Broker, waits for each process to exit and checks that none is alive. The final run confirms HOSTED_SHELL_PRODUCERS_EXITED: 6 before starting a separate reader process that verifies the retained SQL output.

Fault cases drop a start response, reject content publication with an injected HTTP 503 at the SQL-backed Store API, and drop the first successful raw-write response. This is a publication-API failure test, not an injected database-engine failure. Each effect marker remains exactly x, each execution starts once, failed capture blocks further inference, and raw writes are not retried. Physical cancellation settles and permits a subsequent text turn. The two original race scripts replace the owner during parameter reading and output verification; stale preparation and stale receipt admission both reject.

Reproduction

Build the repository and run npm run typecheck and npm run bundle. With Java 21, Maven and Node 22 available, run from the repository root:

mvn -q -f packages/sdk-java/runtime-broker/pom.xml -Dnode.executable="$(command -v node)" -Dtest=RuntimeBrokerServiceTest,RuntimeBrokerHttpServerTest,HttpRuntimeTransportTest,InMemoryRepositoryTest,JdbcRepositoryTest clean install
mvn -q -f packages/sdk-java/managed-agent-server/pom.xml -Phosted-workspace-tools -Dnode.executable="$(command -v node)" -Dtest=WorkspaceRuntimeTest,ManagedSessionStoreIntegrationTest verify

The unchanged default process regression passed on the same product source before the test-only shutdown assertion change; it was not redundantly rerun. To reproduce it, run from integration-tests:

npx vitest run --config vitest.hosted.config.ts

The global CLI 0.24.6 baseline rejects the private Hosted startup path before any model request. This is recorded as an unavailable baseline, not a successful Shell test. The existing file-only profile's Shell refusal is also verified in the real fixture.

Build, typecheck, bundle and focused lint/format checks passed on the unchanged product source. The post-audit verification clean-built and installed the current Broker, reran the stricter real-process test plus Workspace/Store tests, and passed Checkstyle for both Java modules. Test processes and listeners were checked after completion; none remained. Earlier failures exposed and led to fixes for turn checkpoint identity, stale-owner preparation/admission, overlapping pipe writes and misleading temporary-preview-file guidance. The final test assertions distinguish provider preview text from durable receipt metadata.

Limits: H2 is not a real MySQL deployment. Producer shutdown is not a database restart test. Windows, Linux, remote provisioners, real providers, public Artifact APIs and automatic recovery/replay were not validated here.

Additional full-diff audits before review

Three additional open-ended passes covered all 46 changed files and their consumers. The first pass identified a verification gap: requesting Broker shutdown did not prove that worker processes had exited before retained reading. Commit 7a41a5d42 adds the explicit exit barrier. The refreshed integration passes with six producer exits, followed by successful independent output reads. Two subsequent complete passes over the same frozen source found no additional confirmed defects or unresolved suspicions. No product code changed during these additional passes.

Real-stack verification: #12848 Hosted foreground Shell (head 7a41a5d4)

I tested 782c1774. The only later commit, 7a41a5d4, adds 7 lines to HostedWorkspaceToolTurnIT.java, so the production code is identical. This complements the triage review. That review deliberately did not execute the PR's code and asked for someone to run the recovery and retention claims. Everything below was actually executed.

Verdict

• The durability contract holds on real MySQL 8.4.7. The author used H2 in MySQL mode. The PR's own six-Workspace driver passes unchanged. The retained 100 MiB output reads back byte-identical after Spring and mysqld restarts. Every Shell side effect runs exactly once. Cancellation, timeouts, 300 MiB of output and commands longer than 30 s all settle cleanly. I found no correctness blocker in the tested code.
• It cannot merge as-is, for two process reasons:
  1. It is now CONFLICTING with its base. feat(serve): add gated Hosted Workspace file tool turns #12831 moved to c6c76750, and the conflicts are in hosted-workspace-tool-turn.ts and hosted-harness-session.ts, which is exactly the Shell result-commit path. The resolved code needs a re-run; the rig is ready.
  2. No CI has run on this head, because the base is a stacked branch.
• Should fix before real models use this profile: F1. The model-facing preview keeps only the first 8 KiB, so the failure summary and the exit code are cut off. With the same build script, the real model re-ran it in 5 of 6 trials; the ordinary Shell tool re-ran it in 0 of 3. A candidate patch plus tests is below.
• Test gaps: deleting the publisher's bearer check (M13), or never closing the publisher (M11), passes all 899 unit tests and the author's full six-Workspace driver. I also have a candidate test for this.

Rig

PR claims vs evidence

F1: the preview keeps only the first 8 KiB, so failures and the exit code never reach the model

boundedShellPreview() takes the first 8 KiB of the tool text. The core Shell tool deliberately keeps head and tail. shell.ts sets keep: 'both' because that preserves the command's "trailing exit/error summary (where shell failures report)". With raw capture, that truncation is bypassed and replaced by the head-only cut.

• Deterministic check. Probe P2 prints 16 KB of output, then FINAL-42-TAIL, then exit 2. At head the model sees 8,540 B containing neither the tail nor Exit Code:. The notice says only Shell execution: error.
• Real model. build.sh prints 600 progress lines, then an ERROR on stderr, then BUILD FAILED, then exits 3; the tool text is 31,897 B. The preview ends at compiling module 156 ... ok (cache war. How many times build.sh actually ran:

A typical re-run at head: sh build.sh >/tmp/build.stdout 2>/tmp/build.err; echo "EXIT_CODE=$?". With a build this is harmless. With a migration, a deploy or a non-idempotent script, the Hosted profile will now routinely run it twice to find out why it failed.

Candidate (patch): same 8 KiB budget, split as 2 KiB head + a marker + 6 KiB tail, with UTF-8-safe cuts at both ends.

• P2: the tail and the exit code now reach the model.
• The worst-case record shrinks to 54,068 B.
• The nine CLI files pass 901/901 (the patch also adds the auth/close test below).
• The new test fails on the head version.

The tail of the tool text only reaches the end of the output when that output fits in the 64 KiB in-memory buffer (maxBufferedOutputBytes). For larger outputs the exit code still arrives, but the true output tail would have to come from the durable capture. That could be a follow-up.

const PREVIEW_BYTES = 8 * 1024;
const PREVIEW_HEAD_BYTES = 2 * 1024;
const PREVIEW_GAP =
  '\n[... preview truncated; the end of the output follows ...]\n';

export function boundedShellPreview(parts: readonly unknown[]): unknown[] {
  const text = parts
    .map((part) =>
      part && typeof part === 'object' && 'text' in part && typeof part.text === 'string'
        ? part.text
        : '',
    )
    .join('');
  const bytes = Buffer.from(text);
  if (bytes.byteLength <= PREVIEW_BYTES) return text ? [{ text }] : [];
  // Shell failures and the exit status are reported last: keep both ends.
  const head = new TextDecoder().decode(bytes.subarray(0, PREVIEW_HEAD_BYTES), { stream: true });
  let start =
    bytes.byteLength - (PREVIEW_BYTES - PREVIEW_HEAD_BYTES - Buffer.byteLength(PREVIEW_GAP));
  while (start < bytes.byteLength && (bytes[start]! & 0xc0) === 0x80) start++;
  return [{ text: head + PREVIEW_GAP + bytes.subarray(start).toString('utf8') }];
}

F2 (low): is_background: true kills the whole turn, and core Shell tells the model to use it

When core Shell's sleep N guard blocks a command, it tells the model to use is_background: true or the Monitor tool. Neither exists in this profile. If the model follows that advice, execute() throws before dispatch and the whole turn ends turn_error in 109 ms (probe P7), instead of returning a function error the model could recover from. Over 3 real-model runs the guard fired every time and the model never chose is_background: once it reported the block and stopped, twice it used the # intentional-sleep escape. Suggestion: answer profile-refused arguments with a function error response, or tailor the guard text for Hosted.

Test gaps from mutation (one-line mutants, the author's own suites)

TypeScript: 10/20 killed. Java: 5/10 killed.

• M13 (publisher bearer check deleted) and M11 (the turn never closes its publisher) survive the unit tests and the full six-Workspace driver on MySQL. Live, the PR head is correct: 401 without a token or with a wrong one, and the listener is gone after every turn. Under M13, requests reach the handler (409); under M11, listeners pile up 1 → 2 → 3 across turns. The patch above adds a test that passes on head and kills M13.
• The triage review lists several of these guards as the PR's safety properties. They hold at head, but no test pins them:
  • J6: ACK requires a settled execution.
  • J7: v3 is Shell-only.
  • J4: Store kind whitelist.
  • J5: local-process only.
  • J9: inputDigest format.
  • M1: raw-write offset check.
  • M6/M7: accept/receipt equality.
  • C2: seal check on read.
  • C6: read bounded by the declared length.

Notes

• N1, storage growth (declared as a follow-up; here are the numbers). One yes call with a 20 s timeout stored 135,360,328 B of PUBLISHED rows. Extrapolated, that is ~0.8 GB per call at the default 120 s timeout and ~4 GB at the 600 s maximum, with no per-call or per-Session cap. A per-call byte cap would be cheap insurance before this profile leaves private use.
• N2, throughput. Every 64 KiB raw write calls assertWritable(), which renews the writer lease (an HTTP call plus a locked UPDATE on the Session head row). A 64 MiB call made 1,097 writers:renew requests against 68 tool-results:publish, and ran at 4.4 MiB/s; 300 MiB took 58.9 s. Renewing at most every few seconds (the lease is 60 s) would likely lift this.
• N3, resolving the conflict with c6c76750. In this PR, a Shell result's outcomeRef comes from the durable receipt. The oversize fallback in c6c76750 replaces the committed parts. If the fallback were applied to a Shell result while the receipt's outcomeRef is reused, history and the outcome resource would diverge. With the 8 KiB bound, the worst Shell record I could construct is 55.6 KB, so the fallback should never fire for Shell. It is worth asserting that in the resolution.
• Not covered: Windows/Linux, remote provisioners, a worker crash mid-command, and live activation replacement.

Evidence (images, rig scripts, per-run logs, mutation JSON, candidate patch): wenshao/qwen-code@9ab1ced6/pr12848.

@qwen-code /resolve

Qwen Code resolved the merge conflicts and pushed the branch update.

Merge resolution: PR #12848 ← codex/hosted-tool-turn

Merge c3fbb0f00b (parents 7a41a5d42e, c6c767507f); only conflicted files were edited.

Root cause

Base c6c767507f collided with this PR's 782c17749f in two places: the
HostedWorkspaceToolTurn constructor (base swapped the throwing
validateAssistant for a boolean messageFitsInline(type, …); the PR appended an
optional shell?), and the publication path (base added an oversize guard
rebinding converted to an omission receipt; the PR added modelParts, capture,
receipt?.outcomeRef ?? precedence).

Semantic, not adjacent

Resolved tail (converted now let; receipt literal, contract prefix elided):

let outcome = Buffer.from(JSON.stringify({ executionCallId, ...converted[0] }));
if (outcome.byteLength > maxInlineResourceBytes ||
    !this.messageFitsInline('tool_result', converted, model)) {
  converted = [/* bounded omission receipt: outputOmitted, executionStatus */];
  outcome = Buffer.from(JSON.stringify({ executionCallId, ...converted[0] }));
}
const outcomeRef = receipt?.outcomeRef ??
  (await this.session.resources.publish('managed-tool-outcome', outcome));

Load-bearing

• messageFitsInline (required) must precede shell? (optional); both construction
  sites rely on it.
• The guard must stay after the response.response enrichment: it measures the
  committed record, so capture/runtimeError must be on it.
• receipt?.outcomeRef ?? must stay on the publish, with the rebinding before it:
  Shell reuses the publisher's admitted durable ref, a file-tool turn publishes the
  possibly-replaced bytes. Reversing either double-publishes Shell output or commits
  an oversized record.

Not verified

No build, typecheck, lint or test was run.

The guard now covers Shell too, but no test exercises Shell + oversize:
hosted-workspace-tool-turn.test.ts passes no shell; base's new case uses
hosted-workspace-files/1. Were a Shell tool_result to exceed 64 KiB, the omission
receipt drops capture — the pointer to retained output the PR promises the
model. The PR budgets that preview at 8 KiB UTF-8 so escaped JSON plus metadata fit,
so I treated the branch as unreachable. Non-conflicted
hosted-workspace-tool-turn-driver.ts shares the path, bounded by
boundedShellPreview.

Addressed the actionable fixes from the real-stack report in a209f3a, on top of the conflict-resolution merge c3fbb0f. The PR is currently mergeable.

• F1: The same 8 KiB UTF-8 budget now includes up to 2 KiB of head, an explicit gap marker, and the remaining tail. Both cuts preserve UTF-8 characters. Failure summaries and exit codes survive, and the marker says “buffered output” so it does not imply that a >64 KiB process buffer contains the true stream tail.
• F2: Invalid Shell arguments, including is_background: true, now produce durable function-error responses before acquisition or dispatch. A mixed batch is refused in full, with every other call explicitly reported as not executed; the model can correct the batch in the same turn. Failure to persist the refusal remains recovery-blocked.
• M13 / M11: Added missing/wrong bearer tests and real listener-closure checks after completed, model-error, and uncertain-execution turns. Removing the bearer guard, the turn's close call, or the publisher's close call now fails the new tests. These were tested mutations, not inferred coverage.
• N3: An already-admitted Shell result that exceeds the complete history-record limit now blocks before history replacement, checkpoint resolution, and ACK. It cannot substitute an omission response while retaining the original admitted outcome reference. Worst-case JSON-escaped previews retain capture metadata and fit the 64 KiB bound; removing the guard fails its regression test. File-tool omission behavior is unchanged.

Validation on the pushed changes:

• npm run build, npm run typecheck, npm run bundle, changed-file ESLint/Prettier, and two clean full-diff self-audits passed. Independent static review of these seven changed files reported no findings.
• CLI: 912/912 tests across nine relevant files; core: 396/396, including the full ordinary Shell suite; default Hosted process tests: 8/8.
• Java Broker: 374 tests, 1 skipped, no failures; managed-agent-server: 114/114, Checkstyle clean.
• The original six-Workspace integration test passed against the production Java Broker, separate workers, HTTP SQL Store, and H2 in MySQL mode: 100 MiB capture, lost start/raw replies, SQL publication failure, cancellation, and retained reads after all six producer processes exited.
• Fresh F1/F2 bundle verification also passed through real Spring/Broker/worker processes and a deterministic model fixture: a 28 KB Chinese/emoji failure output preserved its head, stdout/stderr failure tails and exit 2 with one execution; a background-Shell + write-file batch produced two function errors with zero starts/effects, then its corrected foreground command succeeded once in the same turn. A 70,000-byte control-character probe preserved exit 3; the largest complete stored tool message was 54,381 bytes, below 65,536. All three prompts ended normally.
• All four targeted mutants (bearer guard, either close call, admitted-result bound) were killed. After restoring production code, all 64 affected tests passed again.

The stacked base still excludes the normal PR trigger. I manually started Qwen Code CI with branch_ref pinned to a209f3a; it is running, not yet a green CI result.

Follow-ups remain explicit: true output tails beyond the 64 KiB buffer, per-call/Session storage quotas (N1), renewal-frequency optimization (N2), and the remaining mutation-coverage inventory (J6/J7/J4/J5/J9/M1/M6/M7/C2/C6 and C4). This correction does not change their production guards or claim to close those test gaps. This round did not repeat the report's real-MySQL restart or real-model repeated-execution trials; the fresh full-stack SQL run used H2.

Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration.

Retargeted this PR to main after #12831 was squash-merged. Deleting the former base branch had automatically closed #12848; it is now reopened, and the temporary branch used to recover it has been removed.

The new head is b89b7b38621a8b2ba3f4a72993097b5fdbd7b352. Its 46-file patch is byte-for-byte identical to the previous head's net change against #12831, and none of those files changed on main in the meantime. Local npm run build, npm run typecheck, npm run bundle, 76 focused CLI tests, 395 focused core tests, and the commit's formatting/lint hooks passed. Maven is unavailable in this local environment, so the Java paths are being verified by the newly triggered main-targeted CI.

@qwen-code /triage

Real-stack re-verification, round 2: #12848 at b89b7b38

This follows up my round-1 report and the fix notes. Those notes said this round did not repeat the real-MySQL restart or the real-model trials, so both are covered here.

Head equivalence. b89b7b38 is a209f3ac squashed onto main 302e7d88. The 46-file PR patch is byte-identical (git diff c6c76750 a209f3ac vs git diff 302e7d88 b89b7b38, ignoring index lines), and none of those files changed on main. Main did bring other changes: V14/V15 migrations, event replay, and edits to hosted-harness-profile.ts and run-qwen-serve.ts. So I rebuilt everything at b89b7b38: TS bundle, Broker 374 tests (1 skipped), managed-agent-server 139/139, checkstyle.

Verdict

All four actionable round-1 items (F1, F2, M13/M11, N3) are fixed, and verified live on MySQL 8.4.7 with a real model where the scenario is reachable. I have no blocking findings. From the real-stack side this is ready to merge. CI on this head is green: Qwen Code CI, SDK Java, Serve A/B and tui-parity. The red Windows job on the earlier manual dispatch at a209f3ac is pre-existing on main. I re-ran it on a GitHub-hosted windows-2022 runner with CI's setup: main 302e7d88 and this head fail the same 14 CLI and 18 core tests, and none of them are in files this PR touches.

What was re-run

About F2 with a real model: in 4/4 trials (2 at this head, 2 at the round-1 head) qwen3.8-max declined to send is_background at all, because the declared schema doesn't have it. So F2 is only reachable through the deterministic probes above, and it is fixed there.

Mutation check on the fixes (the author's nine CLI files, baseline 912/912)

11/12 killed:

• the refusal path disabled (invalid arguments would be dispatched in the foreground)
• the refusal not persisting its tool_result
• the refusal answering only the invalid calls
• the refusal persisting nothing at all
• the N3 guard removed
• the F1 UTF-8 alignment removed, the head removed, the gap marker removed
• M13 bearer check removed; M11 turn close removed; the publisher's own server.close() removed

M13 and M11 both survived in round 1.

Surviving: deleting the size check on the refusal record. It is effectively unreachable, since refusal messages are short. It could be pinned by a test with many calls, but I wouldn't hold the PR for it.

Against the open items in the latest review

That review notes that the executed real-stack results predated the squash. Everything in this report was executed at b89b7b38.

Non-blocking notes

• A single lost status-poll reply blocks the Session. HostedWorkspaceBroker.execute polls every 50 ms and does not retry a failed GET. Dropping one reply blocked the Session (hosted_turn_recovery_required); fail-closed, and the command ran once. The loop is from merged feat(serve): add gated Hosted Workspace file tool turns #12831, but Shell turns poll far longer than file tools: 793 polls for a 45 s command, about 12,000 for a 10-minute one. A few retries of the idempotent status read before declaring the outcome unknown would make long Shell turns much less brittle.

• runtimeError.message is still cut with Buffer.from(message).subarray(0, 1024).toString('utf8') in the worker's finalize. With CJK text this gives 1,026 bytes ending in U+FFFD. The model-facing preview is not affected. This is the same kind of cut F1 fixed; it's a nit.

• The follow-ups from round 1 are unchanged, and the author lists them explicitly: true output tails beyond 64 KiB, storage quotas (N1), lease-renewal frequency (N2), and the older unpinned guards J4–J9, M1, M6/M7, C2, C4, C6.

Evidence (round-2 scripts, per-run logs, mutation JSON, Windows outputs): wenshao/qwen-code@7e4be7d6/pr12848/r2.

Thanks for the round-6 real-stack review. I checked the reported paths against the current head and ran the targeted publisher tests plus the real inherited-pipe regression.

No review threads were unresolved or replied to (0/0). I will keep #12848 open for the remaining review and #12900 dependency; it has not been merged.

感谢第六轮真实环境评审。我按当前分支核对了这些路径，并运行了发布器定向测试及真实子进程继承管道的回归测试。

本轮没有未解决的行内评审线程，也没有回复或关闭线程（0/0）。#12848 将继续保持开放，等待后续评审及 #12900 依赖处理；没有合并。

Synced the merged #12900 and current main into this branch at 0b8ca77b7; the merge had no conflicts. The branch now has one runtime-loss V16 migration and the Session-operation migration at V17. The PR body reflects that #12900 is no longer pending.

Validation on macOS: the frozen-lockfile install ran the repository build and bundle successfully; npm run typecheck passed; the Hosted publisher and Workspace tool-turn suites passed 53/53; git diff --check passed. This host has no JDK, so the new Java/MySQL and MariaDB checks must verify the migration in CI. pnpm continued trying to download unrelated platforms' optional binaries after its successful build and bundle, so I stopped that lingering download process. No source or lockfile changes were made by the sync beyond the merge.

The Workspace lease recovery gap remains tracked in #12904; this merge does not change its fail-closed behavior.

已在 0b8ca77b7 将合入的 #12900 和最新 main 同步到本分支，没有冲突。分支现在仅有一个运行时丢失证据 V16 迁移，Session 操作迁移为 V17；PR 说明也已更新。

本机 macOS 验证：锁文件安装过程成功执行仓库构建和 bundle，npm run typecheck 通过，Hosted 发布器和 Workspace 工具回合测试 53/53 通过，git diff --check 通过。本机没有 JDK，迁移的 Java/MySQL 与 MariaDB 验证交给新一轮 CI。pnpm 在构建及 bundle 完成后仍重试下载其他平台的可选二进制包，我停止了这个遗留下载进程。同步没有引入额外的源码或锁文件改动。

Workspace 租约恢复缺口仍由 #12904 跟踪；本次合并没有改变故障时阻断的行为。

CI follow-up for a4632e984:

Verified on this commit: build, typecheck, ESLint, and the Hosted Harness session test file (20/20). There were no review threads to reply to or resolve in this batch.

Real-stack verification, round 7: #12848 at a4632e98

This round covers the author's reply to round 6 and three commits:

• 14b77fee keeps the partial Hosted Shell output on a drain timeout;
• 0b8ca77b merges main, including fix(managed-agent): Move the Session operation migration to V17 #12900, which moves D4's migration to V17;
• a4632e98 bounds two test waits.

Stack: MySQL 8.4.7; the Spring jar and TS bundle rebuilt at a4632e98; real local-process workers; the fixture model plus real qwen3.8-max.

Verdict

• 14b77fee does what it says on the real stack.
  • When a background process keeps the Shell's pipe open, the durable manifest is now partial / producer_lost instead of unavailable / storage_failed.
  • The accepted prefix reads back through the Store byte for byte, including a 3,000,005-byte prefix spread over several pages.
  • Mutation testing shows the new path, and the worker-failure path it now depends on, are both pinned by tests.
• The main merge fixes the startup failure from round 6. The server starts with V16 and V17. The whole IT class, main's FG6a and FG6b gates, the Shell FG6b variant, the Java suites, the rig scenarios and a real model all pass. SDK Java is green again.
• Unchanged, by design: the Session and the Workspace stay blocked after an incomplete capture.
  • The author keeps this private profile fail-closed and now documents the limitation in the PR body.
  • Workspace-lease recovery is tracked in Hosted Shell: recover a Workspace lease after incomplete pipe capture #12904, and the absolute file_path turn error in Hosted file tools: make invalid absolute file_path a durable refusal #12905.

14b77fee: an unclosed pipe keeps its prefix

Each command ran in its own Session. I stopped the Harness, waited for its lease to lapse, and read every stream back through ResourceToolResultSegmentStore over the Store HTTP API.

• missingRanges records an open tail, [{"start": <n>, "end": null}], on both streams of the partial captures.
• The four minimal background shapes from round 6 split as before. The two compound forms are now partial / producer_lost; sleep 20 … & echo ok and cd . ; sleep 20 … & echo ok still complete.
• As before:
  • The turn is still recovery-blocked, with Complete Shell output was not admitted.
  • Every new Session in that Workspace, with either profile, still gets 409 workspace_busy.
  • The control Workspace still serves new Sessions normally.

The fix is one deleted line: the owner no longer calls failCapture() when a stream finishes with complete: false. That leaves the failed flag on finalize as the only way a worker-side write failure reaches the owner. Four mutants check that path:

Regression at a4632e98

CI on a4632e98

• SDK Java: green in all 8 jobs, including Runtime Broker and Managed Agent MariaDB and Hosted no-tool processes / MySQL 8.4, which were red on 20126bae.
• Serve A/B and tui-parity: green.
• Qwen Code CI: green, including the web-shell E2E smoke.

Merge reference

• Correctness: I see no blocker. Everything from round 6 that belongs in this PR is done: the partial prefix is kept and labelled honestly, and the V16 collision is fixed on main and merged in.
• What remains is the availability decision from round 6.
  • After a backgrounded compound command, the Session and the whole Workspace stay blocked, and no API releases them.
  • A real model wrote that command in 3 of 6 trials.
  • The author keeps it fail-closed on purpose, documents it in the PR body, and tracks recovery in Hosted Shell: recover a Workspace lease after incomplete pipe capture #12904.
• From the real-stack side: mergeable as a private, fail-closed profile, provided hosted-workspace-shell/1 doesn't serve real-model traffic until Hosted Shell: recover a Workspace lease after incomplete pipe capture #12904 lands.

Evidence (probe scripts, per-run logs, IT summaries, the mutation log): wenshao/qwen-code@c250d377/pr12848/r7.

Follow-up to round 7 real-stack verification and the new main conflict:

On d650cdd3f, local build and typecheck passed; related CLI tests passed 50/50 and core tests 11/11. This host has no Java/Maven runtime, so the merged Java integration tests await CI. No review threads required a reply or resolution (0 unresolved).

Real-stack verification, round 8: #12848 at d650cdd3

d650cdd3 merges main e3e7dbcd into a4632e98. It brings in:

• H0c Stage H records (feat(managed-agent): Commit Stage H records and serve the task list (H0c) #12855), which adds migration V18;
• FG6c process-crash gates (test(managed-agent): add FG6c process crash gates #12896);
• the codec digit budget (fix(runtime-broker): enforce the codec reader's total-digit budget #12910);
• other main changes.

Only one conflict involves this PR's files, in ManagedSessionStore (see the author's note).

Stack: MySQL 8.4.7; the Spring jar and TS bundle rebuilt at d650cdd3; real local-process workers; the fixture model plus real qwen3.8-max.

Verdict

• The merge is clean on the real stack.
  • The server starts with V16, V17 and V18. The Java suites pass: Broker 394 (1 skipped) and managed-agent-server 172.
  • H0c's new REFERENCED-only lookup sits next to this PR's pre-published Shell resources without affecting them. Partial and complete captures still read back through the Store byte for byte.
  • Every rig scenario from round 7 gives the same result, and CI is green.
• Main's new FG6c crash gate, re-run with a Shell call, shows no replay and no duplicate effect in any case.
  • Two cases pass unchanged.
  • The others differ from the edit expectations in ways the Shell/v3 design explains.
  • One difference is worth recording for Hosted Shell: recover a Workspace lease after incomplete pipe capture #12904: a Harness crash during a Shell command leaves a finished command recorded as UNKNOWN.
• A correction to rounds 6 and 7.
  • I wrote that FG6b is a manual gate that no workflow runs. That is wrong.
  • CI's Hosted job runs -Phosted-harness-mysql, whose failsafe include is **/Hosted*IT.java. So the whole HostedWorkspaceToolTurnIT class, FG6a and FG6b included, has run in CI since 018f3318; the job logs show FG6B arguments: … there.
  • The Shell variants of FG6b and FG6c are the part CI doesn't run.

The merge

• The conflict: ManagedSessionStore keeps both sides.
  • The PR's publishToolResult path still publishes Shell results as PUBLISHED resources.
  • H0c's storedResource accepts only REFERENCED resources. Its only caller is the Stage H extension-record hook in commit, so pre-published tool results never go through it. That matches the author's description.
• On the stack:

Main's FG6c, re-run with a Shell call

FG6c uses edit on a FIFO so that the tool blocks mid-execution. For the Shell variant I used c=$(cat proof.txt) && [ "$c" = x ] && rm -f proof.txt && printf %s%s "$c" "$c" > proof.txt, which blocks the same way and has the same effect, and left the Java assertions untouched.

• Pass as is: harness-prepare and spring-kill.
• worker-stop: passes once the driver accepts one thing. While the worker is stopped, a status poll gets 503 managed_runtime_unavailable, because the v3 observation asks the worker (30 s timeout); with edit, the Broker answers from its record. The Harness doesn't retry that retryable: true 503, so the turn blocks right away rather than at the end of its observation window. Either way it ends blocked.
• worker-kill: the driver asserts a v2 409 code; Shell gets runtime_execution_evidence_unavailable and then runtime_admission_closed. With those accepted, the Java ledger differs in one row: the binding is LOST, not READY, because the v3 observation notices the dead worker, where the v2 path only reads the Broker's record.
• harness-result: the ledger and the journal-event checks pass. Then the assertion "no managed-tool-outcome resource" fails. The Shell path commits a recordToolResult transaction, holding the outcome and a reference to the capture manifest, before the tool_result message, so a crash at the message commit leaves a committed outcome that the edit path doesn't have yet. That is more durable state, not less, and the cold load is still blocked.
• harness-start: I also ran it on the rig, with edit as a control.

The capture publisher runs inside the Harness, so when the Harness dies the worker cannot finish the capture, and a command that did complete is recorded with an unknown outcome. That is fail-closed, and nothing replays, but it means #12904-style recovery can't learn the outcome of a Shell call interrupted this way. It is worth stating in that design.

Merge reference

• Unchanged from round 7: correctness shows no blocker, and the remaining decision is availability.
  • After an incomplete capture, the Session and the Workspace stay held.
  • As agreed in the author's latest comment, hosted-workspace-shell/1 stays private and serves no real-model traffic until Hosted Shell: recover a Workspace lease after incomplete pipe capture #12904 provides recovery.
• FG6c adds one input for Hosted Shell: recover a Workspace lease after incomplete pipe capture #12904: a Harness crash during a Shell call leaves a completed command recorded as UNKNOWN.
• From the real-stack side, d650cdd3 is fine to merge on those terms.

Evidence (probe scripts, the FG6c Shell driver diffs, per-run logs, IT summaries): wenshao/qwen-code@60e8cf13/pr12848/r8.

Follow-up to round 8 real-stack verification and the latest main conflict:

On dfabe7c7c, build, typecheck, formatting, and related CLI tests (50/50) passed locally. This host lacks Java/Maven, so FG6d and the merged Java gates await CI. No review threads required a reply or resolution (0 unresolved).

@qwen-code /triage

Real-stack verification, round 9: #12848 at dfabe7c7

dfabe7c7 merges main 92f4d4f6 into d650cdd3. It brings in:

• FG6d Hosted cancellation gates (test(managed-agent): add FG6d hosted cancellation gates #12924);
• main's own fix for the same Hosted test wait (test(cli): give the hosted tool-turn waitFor an explicit timeout (#12911) #12915);
• unrelated CLI, core and VS Code changes.

No production file of this PR changed, and Java production code is identical to d650cdd3. The two conflicts are both in test files (see the author's note).

Stack: MySQL 8.4.7; the round-8 Spring jar; the TS bundle rebuilt at dfabe7c7; real local-process workers; the fixture model plus real qwen3.8-max.

Verdict

• The merge is correct.

  • HostedWorkspaceToolTurnIT keeps main's new cancellation branch and this PR's index < 2 check.
  • The class passes 4/4 locally on MySQL (90.7 s) and in CI, FG6d's 4 cases included.
  • Every rig scenario from round 8 gives the same result, and CI is green.

• Cancelling a running Hosted Shell works, and cleanly. FG6d uses edit, which can't be interrupted. On the stack, a cancelled Shell call:

  • settles as cancelled in about 1.3 s with a complete capture;
  • kills its process group, including a background loop and a compound command that holds the pipe;
  • frees the Session and the Workspace.

• One more input for Hosted Shell: recover a Workspace lease after incomplete pipe capture #12904: for Shell, the Workspace lease is not a single-writer guarantee. A descendant that leaves both the pipe and the process group, for example via setsid with its output redirected, keeps writing:

  • after a turn that completed normally, with a complete capture and the Workspace released;
  • after a clean cancellation.

  In one run, a second Session that took the same Workspace read that descendant's write in its own command output. This fits the PR body's note that the profile is not a filesystem sandbox. It also means that holding the lease on an incomplete capture doesn't cover this case.

The merge

FG6d's question for Shell: cancelling a running command

Each command ran in its own Session and Workspace. I cancelled it 2 s after the Broker reported EXECUTING, then waited 35 s for late effects.

So cancellation is a working exit even for the compound background shape, as long as the foreground command is still running. The Workspace hold from rounds 6 and 7 only happens once the foreground has already exited.

Input for #12904: detached descendants outlive the lease

1. Session A runs perl -MPOSIX -e 'POSIX::setsid(); sleep 6; …append "from-detached-descendant" to shared.txt…' >/dev/null 2>&1 & echo ok. The turn completes normally, the capture is complete, and the Workspace is released.
2. Session B, in the same Workspace, starts right after. It runs echo from-next-session >> shared.txt; sleep 8; cat shared.txt, and its own output reads:

from-next-session
from-detached-descendant

The descendant left both the pipe (output redirected) and the process group (setsid). Neither the drain boundary nor the group kill sees it, so the capture is complete and the lease is released while it is still running.

• Existing wording: the PR body already says the profile "is not a filesystem sandbox", and the author's round-6 reply says pipe EOF and a group kill don't prove descendants stopped.
• What this adds:
  • The same gap exists on the success path, not only on incomplete captures.
  • So keeping the lease after an incomplete capture protects against pipe holders, but not against fully detached writers.
• Worth stating in Hosted Shell: recover a Workspace lease after incomplete pipe capture #12904 together with round 8's UNKNOWN-after-Harness-crash case.

Merge reference

• Unchanged: correctness shows no blocker.
  • The remaining decision is availability, plus now the scope of the Workspace-lease guarantee for Shell.
  • As the author agreed, hosted-workspace-shell/1 stays private and serves no real-model traffic until Hosted Shell: recover a Workspace lease after incomplete pipe capture #12904.
• From the real-stack side, dfabe7c7 is fine to merge on those terms.

from-next-session
from-detached-descendant

Evidence (probe scripts, per-run logs, the IT summary): wenshao/qwen-code@88dd8cfd/pr12848/r9.

Round-2 review disposition — all 39 threads handled

Every unresolved round-2 thread was re-verified against current main before being answered in place and is now resolved. Disposition:

The verification evidence and provenance for each item is in its thread reply; #13307 groups them by package. The two comments the round-2 review flagged as "Unresolved, please confirm" are closed out as follows: the duplicate-V16 startup failure from real-stack round 6 was fixed on main by #12900 (V17 renumber) and confirmed green in round 7; the Session/Workspace stay blocked after an incomplete capture behavior is by design fail-closed for this private profile, with Workspace-lease recovery tracked in #12904 (open); the round-1 sandboxed verification's only Major finding was re-measured by the round-2 sandboxed run and does not reproduce (the publisher registry is keyed per turn via promptId).

For the record: getting these fixes here surfaced one false start worth naming — a full-suite run on the rebased branch showed a single failure whose identity was lost to output truncation; two subsequent identical full runs passed 381/381 each, so the suites stand green.