tracking(harness): reduce readiness, tool, archive, browser, and research friction #4267

Activity

1. liugddx

   added

   enhancementNew feature or requestNew feature or request

   on Aug 30, 2026
2. liugddx commented on Aug 30, 2026

   

   liugddx

   on Aug 30, 2026

   MemberAuthor

   More actions

   Source audit + verdict revision

   I ran a source-level audit of main against all 12 friction areas. Summary: the umbrella holds up as a record of real session friction, but ~70–80% of the individual items need to be narrowed, reclassified, or withdrawn before they become an engineering worklist. I've added a post-audit status block and a verdict table to the issue body; details and the reasoning per item are below.

   Methodological correction (applies to #6 and #10 especially)

   A source audit proves what the code on main should do. It does not prove that the observed friction was absent in the actual build / Runtime composition / Client Capability path that produced this report. Where a source invariant contradicts a runtime observation, the honest verdict is "conformance investigation needed," not "refuted by source." I over-stated two items on the first pass and have corrected them below.

   Withdrawn

   • Land Runtime v2 architecture and AgentRun wiring #8 (tool-schema boilerplate) — timeout_ms, run_in_background, pty are .optional(); boundary_intent has a .default('current'); required_boundary is optional and boundary fields are dropped from the schema entirely when the host has no sandbox boundary (shell-tools.ts). Only command/ref are required. The per-call verbosity in the session was conservative model behavior, not a server requirement. At most this is a "does the provider-visible schema express optional/default clearly" question.
   • Prefer RuntimeEvent model history when complete #11 (env once+deltas) — the per-turn env tail is deliberate: it's kept out of the durable/cached system prefix precisely to avoid prefix-hash churn, and the model must see the current date/branch/boundary each turn (session-environment-prompt.ts). It's already budgeted and capped. "Send once + deltas" would regress the prompt-cache design. Only compaction of the per-turn serialization is on the table.

   Narrowed (real, but smaller than stated)

   • Extract runtime kernel boundaries and durable AgentRun recovery #3 (archive) — a direct-return threshold already exists (payloads ≤~2048 est. tokens are not archived; superseded ≤256 kept verbatim). The "small/immediately-needed results also become indirect" framing is over-stated and should be dropped. The genuine gaps are: search-within-archive, line-oriented reads, a section/positional index, decoded (un-escaped) paging, and previews. Separately: Shell stdout is tail-truncated at capture time (head dropped), so "recover the complete output" is an upstream Shell capture/preservation contract, not something ArchiveRead can deliver alone. Split into two problems.
   • Add Runtime v2 implementation skeleton #5 (bypass) — AskUserQuestion genuinely has no permission authority (it returns selected text only), and there is intentionally no model-invokable switch-to-bypass (bypass is a user privilege). But the remedial control already ships: RequiresBypassBanner → setPermissionMode('bypass') → regenerate, with a fresh boundary read on the next call. So "add an actionable control / re-read boundary on retry" is already done. The remaining real gaps are (a) steering the model away from presenting an AskUserQuestion option that looks like it switches modes, and (b) an observable permission_mode_changed event so the change is visible without a blind retry. Retitle to "Align requires_bypass model guidance, native banner handling, and observable boundary-transition state."
   • Wire RuntimeRunner through SessionManager #7 (WriteStdin) — confirmed: the provider-visible schema and the strict validator diverge (payloads the loose schema accepts are rejected after normalization; the validator also accepts an input field the schema doesn't advertise). This is intentional provider tolerance (providers inject null/0 placeholders) and is already backstopped by a normalizer + a conformance test. But the contract is still model-hostile: from the published schema the model can't derive a reliable minimal key payload. Fix = an end-to-end conformance pipeline (loose provider schema → normalizer → discriminated union → strict validate) with at least one minimal legal example per action type, plus a minimal example in the tool description. Keep both layers; don't collapse to one union.

   Reclassified: existing mechanism, investigate presentation — do not build a second authority

   • Persist RuntimeEvents per AgentRun #10 (completion/retry state) — the backend already has terminal-state events (run_completed|failed|cancelled), continuation admission, provider-retry events, and a durability latch (agent-run.ts). So: no second terminal-state authority. But the session's actual problem — user/model couldn't tell whether the previous response was fully delivered — may live in streaming delivery / renderer / remount / persistence, not the state model. Mark investigate: given a persisted terminal AgentRun, does Desktop distinguish fully-rendered / persisted-but-partially-delivered / output-limited / interrupted-before-terminal? If the projection already answers, it's UI-only; if not, add projection fields.
   • Add RuntimeEvent read model projection #12 (task progress) — Agent Graph projection, timeline rollup, task-ledger ownership (child→main), and a desktop progress panel already exist. Not a missing model. If ordinary tool-heavy turns feel opaque, that's whether such turns enter these projections and how prominently the UI shows them — a product-presentation/scope discussion, better tracked under the desktop-UX umbrella than here.

   Confirmed as real gaps

   • Add Rive workflow Maka tool #1 (PATH/dylib) — confirmed and, if anything, sharpened. Readiness probes a fixed /bin/sh -c true and renders Command sandbox: available; it does not prove the selected executable can load its dylib closure. A full Mach-O dependency resolver already exists but only serves Maka's own Node/ripgrep helpers — ordinary Bash commands don't reuse it. Retitle to: "Command-sandbox availability proves shell construction, not that the selected executable can load its runtime dependency closure." Fix should stay cautious — resolving the initial Mach-O closure does not cover runtime dlopen, plugins, or child processes using different executables, and boundary expansion must be bounded and logged (explicit executable → bounded dependency resolution → read-only expansion → record actual expansion). At minimum, report dependency_blocked accurately in readiness.
   • Harden runtime, storage, gateway, credentials, and IPC inputs #2 (/tmp) — confirmed code inconsistency: the Bash path passes literal /tmp while every other path (diagnostics, fs-worker) canonicalizes to /private/tmp; on macOS /tmp is a symlink, so a writable subpath "/tmp" can miss a write the kernel resolves under /private/tmp. Status: confirmed inconsistency + runtime hypothesis + needs macOS reproduction. Split into a small bug ("canonicalize /tmp consistently before building the macOS Bash sandbox") with an acceptance test that actually writes to a real mktemp /tmp/... file, not just asserts a policy string.
   • Document Runtime v2 architecture evolution #4 (GitHub research) — confirmed: no native structured GitHub tools exist; the only surface is generic WebFetch/WebSearch (+ shell gh), and WebFetch returns truncated page text with no canonical URL/author/state/labels/comments. Open question is placement: a GitHub Research skill/plugin (anonymous-first REST + Discussions fallback, lazy-loaded via tool-search) is the lower-risk near-term option; promote to a core forge adapter once usage justifies it. Note there is no GitHub credential path in the repo today, so "unauthenticated-first" must handle 401 and the Maka-Agent/maka-agent → apache/maka redirect internally.
   • Fix Runtime v2 runner and flow contracts #6 (browser visibility) — this is the one I initially mis-called "refuted by source," and I'm retracting that. Source enforces a strong visible-lease invariant ("every action must target the conversation on screen; the agent can never drive or read a view the user can't see"). But the session observed: browser_navigate succeeded to a GitHub login page, browser_snapshot read content, snapshot reported viewport: 0x0, and the user explicitly said they couldn't see the browser; the working fallback was open https://github.com/login/device. A source invariant cannot overrule a first-hand "I can't see it." Correct verdict: runtime/source contradiction — identify the active browser provider/build/composition and add conformance telemetry (tool provider id, Runtime Host revision, desktop build revision, browser session id, visible-lease state, actual viewport dims, panel mounted/selected). The independent gaps the audit did confirm still stand: open-in-system-browser, a device-code/OAuth handoff primitive, a hard credential-entry boundary, and post-auth session-reuse policy.
   • Wire AiSdkFlow into SessionManager runtime path #9 (capability groups) — confirmed and likely the best effort/value ratio: native tools currently collapse into a synthetic other group, while a real taxonomy (categoryHint/ToolCategory) already classifies every tool for permissions. Wiring that into tool-search groups needs no schema loading. Confirm first: permission-category vs discovery-category semantics match, a tool may need multiple discovery tags, other stays as fallback, and grouping never changes permissions. The Paseo skill naming/tool mismatch (create_agent vs agent_spawn, product/CLI/state-dir divergence) is real but originates from an external, user-global skill — so any "validate a skill's declared tools exist" work is about hardening against externally-installed skills and should warn, not hard-fail.

   Recommendation

   Keep the issue — it records real experience and the audit found nothing fabricated. But drive follow-up from the verdict table, and split sub-issues only for the highest-confidence items first: macOS Bash dependency/canonicalization, tool-search native groups, GitHub research capability, ArchiveRead search/line reads, browser-visibility conformance, and the WriteStdin schema-pipeline conformance.

   🚀React with 🚀1Reacted by Wang

   👀React with 👀1Reacted by Wang
3. Astro-Han commented on Aug 30, 2026

   

   Astro-Han

   on Aug 30, 2026

   Contributor

   More actions

   The sandbox findings here appear to share one architectural cause and should not be addressed through separate path exceptions or additional model-side negotiation state.

   I suggest converging the sandbox design through #3629:

   • one revisioned, Session-scoped SandboxPolicy: auto | full_access | external;
   • Runtime evaluates ordinary tool calls before first dispatch;
   • approval and policy changes are owned by Runtime, not the model;
   • remove request_sandbox_boundary, boundary_intent, required_boundary, and negotiation counters;
   • Bash runs under the current policy without per-command escalation;
   • platform toolchain dependencies are provided by a fixed, read/execute-only backend substrate rather than an expanding path allowlist.

   #4234 has already addressed /tmp canonicalization. The remaining Command Line Tools/Homebrew failures should help define and test the backend substrate, while #3629 owns the cross-platform architecture decision.

   Concrete reproducible failures can remain scoped sub-issues, but they should converge on this shared Runtime-owned model rather than introduce independent fixes.

   中文

   这里的多项 sandbox 问题具有共同的架构根因，不应分别通过路径特例或新的模型侧协商状态解决。

   建议统一通过 #3629 收敛：

   • 使用唯一、Session 级、带 revision 的 SandboxPolicy；
   • Runtime 在工具首次执行前完成判定和审批；
   • 删除模型侧提权工具、声明参数和 negotiation counters；
   • Bash 只在当前 policy 下执行，不支持逐命令提权；
   • 系统工具链依赖由 backend 提供固定的只读/执行 substrate，不再不断扩张路径白名单。

   #4234 已解决 /tmp canonicalization。剩余 Command Line Tools/Homebrew 问题应作为 backend substrate 的真实验收场景。具体故障可以拆分子 Issue，但最终都应收敛到同一个 Runtime-owned 架构。

   AI assistance disclosure: OpenAI Codex, Claude, and K3-256K assisted with the architecture and naming analysis. I reviewed this proposal and take responsibility for it.
4. liugddx commented on Aug 31, 2026

   

   liugddx

   on Aug 31, 2026

   MemberAuthor

   More actions

   Follow-up tracking review (2026-08-31)

   A review of the current public issue/PR graph shows that implementation has started, but the post-audit work has not yet been split into native GitHub sub-issues.

   Direct implementation underway

   • fix(runtime): admit macOS Bash toolchain dependencies #4279 — open, non-draft, unmerged: fix(runtime): admit macOS Bash toolchain dependencies (Refs #4267). It adds a fixed read/execute-only substrate for Homebrew package roots and Apple developer roots, treats inaccessible Git global/system config as absent, and adds real Seatbelt regression coverage for Homebrew and Apple Git startup.
   • This directly addresses the reported macOS dylib/toolchain failure in item 1, but it is not yet a general executable dependency-readiness probe and does not state that it fixes the /tmp ↔ /private/tmp inconsistency in item 2.

   Existing related tracking

   These issues/PRs overlap with parts of the umbrella but are not replacements for the narrowed post-audit gaps:

   • product(readiness): define a scope-aware task submission snapshot #2497 — scope-aware task-submission readiness snapshot; relevant to item 1/readiness, but not specifically executable dylib-closure probing.
   • fix(headless): register ArchiveRead when Harbor enables tool-result archiving #2025 + merged PR fix(headless): register ArchiveRead when Harbor archives tool results #2028 — fixed Harbor enabling the archive writer without exposing ArchiveRead.
   • refactor(runtime): make the tool-result archive capability indivisible #2026 — makes the archive writer/readers/tool an indivisible capability.
   • [RFC] Provider-native Tool Search for large tool catalogs #1382 — provider-native Tool Search for large catalogs; related to item 9, but does not by itself wire native tools into capability-family/category groups.
   • Move sandbox approval into Runtime pre-dispatch #3629 — Runtime pre-dispatch sandbox approval discussion; adjacent to item 5.
   • roadmap(product): evolve Maka into a durable Agent workspace #2469 — durable Agent workspace roadmap; relevant to task-state/progress and presentation.
   • refactor(storage): replace replay Artifact paths with a SQLite context-offload store #4071 — context-offload storage direction; related to archive durability/storage, not ArchiveRead search/line-read ergonomics.

   The archive work above fixes registration/composition and storage concerns. It does not cover the remaining item 3 requirements: search within an archive, line-based reads, section indexes, and decoded paging.

   High-confidence work not yet found as dedicated tracking

   No dedicated public issue/PR was found for the following narrowed work items:

   • item 2: macOS /tmp → /private/tmp canonicalization repro/test and remaining fix;
   • item 3: ArchiveRead search, line reads, section index, and decoded paging;
   • item 4: structured, unauthenticated-first GitHub Issue/Discussion research tools;
   • item 5: requires_bypass model guidance plus an observable boundary-change event;
   • item 6: browser visible-lease/provider/build conformance investigation for the observed viewport: 0x0 drive;
   • item 7: WriteStdin provider-loose-schema → normalizer → discriminated union → strict-validator conformance and minimal per-action examples;
   • item 9: wiring categoryHint / ToolCategory into deferred native-tool search groups;
   • item 10: persisted terminal response state versus actual Desktop delivery/render conformance.

   Items 8 and 11 were withdrawn by the audit. Item 12 should remain a product-presentation/scope discussion over the existing projection rather than create another progress authority.

   Suggested issue split

   To make this umbrella actionable and independently reviewable, create dedicated issues in this order:

   1. macOS temp-root canonicalization conformance (item 2);
   2. deferred-tool native category groups (item 9);
   3. WriteStdin schema-pipeline conformance (item 7);
   4. ArchiveRead search/line-read/index ergonomics (item 3);
   5. structured public GitHub research capability (item 4);
   6. browser visible-lease conformance telemetry/investigation (item 6);
   7. requires_bypass guidance and boundary-change observability (item 5);
   8. terminal-state persistence versus Desktop delivery/render investigation (item 10).

   At the time of this review, #4267 remains open with no assignee or milestone, and GitHub reports sub_issues_summary.total = 0. #4279 is the only direct implementation PR found that explicitly references #4267.
5. liugddx

   added sub-issues on Aug 31, 2026

   • harness: wire native tool categoryHint/ToolCategory into deferred tool-search groups (item 9 of #4267) #4353
   • harness: WriteStdin provider schema and strict validator conformance (item 7 of #4267) #4354
   • harness: ArchiveRead search / line reads / section index ergonomics (item 3 of #4267) #4355
6. liugddx

   added a commit that references this issue on Aug 31, 2026

   test(runtime-host): refreeze headless coding wire contract for Archiv…

   ...

   7b1fa27
7. liugddx commented on Sep 1, 2026

   

   liugddx

   on Sep 1, 2026

   MemberAuthor

   More actions

   Additional live-session conformance evidence

   A second extended session exercising this umbrella reproduced several of the original friction areas and exposed one narrower catalog/invocation defect that should be tracked separately.

   Directly reproduced

   • Item 3 — ArchiveRead ergonomics: large GitHub/API/shell results repeatedly required inspect -> read(offset) -> read(next offset). There was no archive-local search or line coordinate space, and locating later objects in archived JSON required guessing character offsets. This materially increased tool calls and made selecting/copying the correct archive ref error-prone.
   • Item 4 — GitHub research: reconstructing Issue/PR status required WebFetch, GitHub REST Search, direct REST endpoints, browser capability, authenticated gh, GraphQL review-thread queries, and local Git refs. Direct comments/timeline calls sometimes returned 403 while Search remained usable. Search also produced lexical false positives that had to be manually distinguished from explicit Refs/Closes relationships.
   • Item 5 — boundary UX: browser and Windows shell work reported requires_bypass / sandbox unavailable. The Session boundary could not be changed by an ordinary question response; the user had to switch to Bypass manually and send another turn before work could continue.
   • Item 6 — browser visibility conformance: the automated browser snapshot again reported viewport: 0x0. Its GitHub context was logged out while the local gh CLI was authenticated through the keyring. This is fresh runtime evidence for the visible-lease/provider/build investigation and for the missing user-authentication handoff.
   • Item 9 — capability discovery: deferred capability discovery remained difficult enough that shell/browser fallbacks were needed before the effective capability map was clear.
   • Item 12 — progress presentation: during long PR review work, raw tool/archive traffic was visible but task-level phase/completion was not sufficiently legible; the user had to send “continue” more than once. This supports treating the remaining gap as projection delivery/presentation rather than creating another progress authority.

   Runtime/source mismatch evidence

   The current Client-visible Bash invocation schema still required explicit values for:

   {
     "timeout_ms": 120000,
     "run_in_background": false,
     "pty": false,
     "boundary_intent": "current"
   }

   Item 8 was withdrawn after the source audit because these fields are optional/defaulted in main. The observed required schema should therefore be investigated as Client/provider-schema/runtime-composition conformance evidence, not as a reason to restore the withdrawn design proposal unchanged.

   Newly narrowed defect: Agent catalog → invocation conformance

   The session attempted to delegate three read-only PR reviews. agent_list advertised:

   agent_id: local-read
   profile: local_read
   status: available
   

   but three subsequent agent_spawn calls using that advertised identity all failed with:

   Unknown subagent_id "local-read". Call agent_list first.
   

   agent_list had just been called. This is adjacent to item 9, but more specific than capability-family grouping: the discovery surface and invocation surface expose incompatible identity/profile namespaces and the repair text is not actionable. It should be split into a dedicated catalog/invocation conformance issue with an acceptance test of:

   list available agent/profile
   -> select the returned callable identity
   -> spawn succeeds, or list marks it non-callable and provides the exact supported selector
   

   Adjacent observations, not yet claimed as #4267 defects

   • A dirty workspace with extensive tracked deletions was discovered only after repository work began. A scoped readiness projection could surface branch/dirty-state facts earlier, but the workspace condition itself is not necessarily a Maka defect.
   • Several malformed/poorly composed PowerShell Git commands timed out with no output. Those calls were corrected by the agent; richer timeout/pager/process-state diagnostics would help, but the command error itself should not be attributed to Maka.
   • GitHub 403 responses may originate from upstream rate limits/auth policy. The Maka concern is the lack of one structured fallback path, not that every external failure is a harness defect.

   No P0 authority violation or data-loss behavior was observed. The dominant cost remained plumbing between mechanisms that individually exist but are not yet easy to discover, compose, or hand off.
8. liugddx

   added a commit that references this issue on Sep 2, 2026

   feat(runtime): give ArchiveRead search, line reads, and decoded paging (

   ...

   608b509
9. Astro-Han

   added 2 commits that reference this issue on Sep 2, 2026

   fix(runtime): make the WriteStdin contract derivable and drift-proof (#…

   ...

   5d21845

   feat(runtime): bucket ungrouped native tools by categoryHint in tool …

   ...

   07f5cb5
10. liugddx commented on Sep 4, 2026

    

    liugddx

    on Sep 4, 2026

    MemberAuthor

    More actions

    Follow-up audit evidence: Windows sandbox, child-run provenance, and long-operation continuity

    This is a follow-up from another real extended Maka session on Windows. The task was a long desktop release flow involving repository inspection, an isolated release worktree, deterministic tests, packaging, artifact upload, and online verification.

    This comment does not propose reopening the ArchiveRead interface work already marked resolved. It records new reproductions and suggests routing them into focused issues.

    Summary

    The session exposed six distinct problems:

    1. An approved Windows execution boundary still could not instantiate managed Bash.
    2. The same sandbox failure also blocked structured filesystem tools through an ACL-ledger mutex.
    3. Agent discovery returned identifiers that agent_spawn did not accept.
    4. Jans/worktree child execution rejected a dirty parent even though the requested child was commit-isolated.
    5. A completed scheduled agent_run did not expose a durable child result or receipt to the parent session.
    6. Long-running operation, Goal, Agent Graph, and response terminal states were not reconciled into one understandable execution lineage.

    The final external state changed successfully, but the parent session could not retrieve enough evidence to independently prove all requested quality gates and Git operations. This is precisely the type of authority/provenance gap that becomes visible only in a real extended task.

    ---

    A. Approved Windows boundary, but managed Bash remained unavailable

    Reproduction

    The parent session requested:

    • write access to the repository subtree;
    • process network access.

    The boundary request returned an approved managed profile.

    The immediately following PowerShell invocation still failed with:

    Command sandbox is required but unavailable on platform win32.
    

    Retrying with an explicit expanded boundary produced the same error.

    Expected

    Before accepting or applying the boundary, Runtime should know whether the Windows command sandbox can actually be instantiated.

    After approval, a bounded readiness probe should distinguish:

    boundary approved
    command sandbox instantiated
    shell executable launched
    workspace read/write usable
    network usable
    

    Actual

    The UI/API reported a successfully approved boundary, while the effective command capability remained unusable.

    Suggested acceptance criteria

    • On Windows, task readiness includes a real bounded command-sandbox startup probe.

    • An approved boundary cannot be presented as executable until sandbox instantiation succeeds.

    • Failure uses an actionable reason code such as:

      command_sandbox_unavailable
      

    • The failure explains whether retry, Runtime restart, Client restart, or another execution surface is required.

    • An unsuccessful sandbox application does not leave an unnecessarily broad effective grant behind.

    This is related to dashboard item 1, but it is a concrete Windows sandbox-instantiation reproduction rather than another PATH/dependency-closure example.

    ---

    B. Sandbox failure also blocked structured filesystem tools

    After the managed Bash failure, ordinary structured file operations such as Read and Glob repeatedly failed with:

    maka-windows-sandbox: acquire ACL ledger mutex timed out
    

    and:

    Filesystem worker failed: worker_io_incomplete
    

    The same error occurred in a read-only child Agent.

    Impact

    This converted one unavailable capability into a session-wide repository outage:

    managed Bash unavailable
      -> filesystem worker cannot acquire ACL ledger
      -> Read/Glob also unavailable
      -> parent and child Agents cannot inspect repository state
      -> no local recovery or diagnosis path remains
    

    The parent session had already received boundary approval, but could neither execute commands nor read files.

    Suggested acceptance criteria

    • A failed command-sandbox initialization must not permanently block structured filesystem tools.
    • ACL-ledger acquisition must have bounded recovery rather than repeated opaque timeouts.
    • Diagnostics should identify:
      • the ledger owner;
      • acquisition start time;
      • stale-lock status;
      • whether automatic recovery was attempted.
    • Runtime should expose a safe session-scoped sandbox reset/reinitialize action.
    • A read-only child should not inherit an unrelated stale write-boundary mutex.

    Suggested focused issue:

    fix(windows-sandbox): approved boundary can leave Bash unavailable and filesystem workers blocked on the ACL ledger
    

    ---

    C. agent_list identifiers were not accepted by agent_spawn

    Reproduction

    agent_list advertised legacy profiles including:

    local-read
    implementation
    

    The parent then called agent_spawn with the advertised identifier:

    subagent_id = "local-read"
    

    Runtime rejected it with:

    Unknown subagent_id "local-read". Call agent_list first.
    

    agent_list had already been called.

    Expected

    Every identifier advertised as spawnable should either:

    1. be directly accepted by agent_spawn; or
    2. include an explicit invocation mapping, for example:

    {
      "id": "local-read",
      "invocationKind": "legacy_profile",
      "spawnField": "profile"
    }

    Actual

    Discovery and invocation used incompatible identity namespaces, and the recovery message incorrectly asked the caller to repeat an operation it had already performed.

    This is a current independent reproduction of the catalog-to-invocation identity mismatch mentioned under dashboard item 9. It should not reopen capability-family discovery itself.

    Suggested acceptance criteria

    • Add a conformance test that invokes every item returned by agent_list using its advertised invocation shape.
    • Distinguish agent_id, subagent_id, and legacy profile in the schema.
    • Do not return “call agent_list first” when the current session has already done so.
    • Unsupported legacy profiles should be marked non-spawnable rather than advertised as available.

    Suggested focused issue:

    fix(agent-orchestration): identifiers returned by agent_list must have a valid agent_spawn invocation
    

    ---

    D. Commit-isolated worktree child was blocked by a dirty parent

    A requested implementation child failed during topology provisioning with:

    Worktree child execution requires the source Git worktree to have no uncommitted changes
    

    The task explicitly requested an isolated release worktree based only on the latest committed source and explicitly prohibited including or overwriting parent uncommitted changes.

    Why this is surprising

    A Git worktree created from a named commit does not need to include parent working-tree changes. Requiring a clean parent removes much of the value of commit-isolated child execution:

    parent has unrelated untracked/modified files
      -> child should start from parent HEAD
      -> child receives no uncommitted parent content
      -> parent remains untouched
    

    Suggested acceptance criteria

    • Worktree child execution can start from an explicit commit while the parent working tree is dirty.
    • The UI clearly states that uncommitted parent changes are excluded.
    • If the user requests inclusion of uncommitted changes, Runtime can:
      • create an explicit patch/snapshot;
      • request confirmation;
      • or reject that different operation.
    • Unrelated untracked files do not block a commit-based isolated child.
    • Failure diagnostics identify the exact policy and available alternatives.

    Suggested focused issue:

    fix(agent-worktree): allow commit-based isolated child execution from a dirty parent worktree
    

    ---

    E. Completed scheduled Agent had no durable result link

    As a fallback, the session created a one-shot scheduled task with an agent_run effect.

    The scheduled-task list later reported:

    <task title> | completed | effect=agent_run
    

    However, the completed task did not expose:

    • child session ID;
    • child run ID;
    • result record ID;
    • terminal response;
    • artifact references;
    • command/test receipts;
    • start and finish timestamps.

    The parent could verify that the external stable manifest changed from one version to the next, but could not retrieve the child execution evidence needed to prove:

    • complete quality gates passed;
    • packaged smoke passed;
    • the expected release branch was pushed;
    • the expected Git tag was pushed;
    • each online binary was independently downloaded and hashed.

    Expected result shape

    A completed agent_run should expose something similar to:

    {
      "taskId": "...",
      "status": "completed",
      "sessionId": "...",
      "runId": "...",
      "resultRecordId": "...",
      "startedAt": "...",
      "finishedAt": "...",
      "artifacts": [],
      "terminalState": "completed"
    }

    The parent should be able to call a direct operation such as:

    ScheduledTask get-result <task-id>
    

    Scope note

    This is not an ArchiveRead retrieval-ergonomics problem. ArchiveRead cannot retrieve a result that ScheduledTask never links into the parent-visible execution lineage.

    Suggested focused issue:

    fix(scheduled-agent): completed agent_run must expose its child run and durable result receipt
    

    ---

    F. SearchHistory first-page cursor appeared impossible to construct

    The parent attempted to locate the scheduled child through history search.

    The visible invocation required a cursor. Candidate initial values such as "0" and "/" were rejected with:

    Search cursor is invalid or belongs to another query.
    

    If the backend only accepts a continuation cursor produced by an earlier query, the first query has no valid cursor source.

    Suggested acceptance criteria

    • The first search request allows the cursor to be omitted or set to null.
    • Only continuation requests require a server-issued cursor.
    • The schema documents the first-page call separately from pagination.
    • A minimal provider-visible first-page payload has a conformance test.

    Suggested focused issue:

    fix(history): allow first-page SearchHistory calls without a continuation cursor
    

    This is a new schema/runtime-contract reproduction, not a reopening of the resolved WriteStdin case.

    ---

    G. Agent Graph repeatedly emitted a terminal checkpoint with no usable result

    The Agent Graph entered a terminal state containing:

    • one superseded work item;
    • one topology failure;
    • zero running operators;
    • no selected result.

    The same durable supervisor checkpoint was injected repeatedly with the same snapshot hash, asking the parent to inspect the graph and read child results even though no child result existed.

    Expected

    • A given terminal snapshot is surfaced once unless its state changes.
    • A fully terminal graph closes or presents one explicit recovery action.
    • The supervisor does not request agent_output view=result when no result record exists.
    • Topology failures are rendered as terminal failures with actionable alternatives.

    Actual impact

    The repeated checkpoint messages consumed turns and context without changing the graph or enabling recovery.

    Suggested focused issue:

    fix(agent-graph): deduplicate terminal supervisor checkpoints and do not request nonexistent child results
    

    ---

    H. Goal continuation did not share evidence with child execution

    The parent created a Goal with explicit acceptance conditions covering:

    • isolated release worktree;
    • quality gates;
    • packaged smoke;
    • branch/tag push;
    • online artifact verification.

    The continuation layer later reported:

    Evaluator call failed (continuing)
    

    Meanwhile, the scheduled child independently completed, but its result was not attached to the Goal evidence.

    Expected

    Goal evaluation should consume the structured receipts of foreground, graph, and scheduled child operations.

    Suggested acceptance criteria

    • Goal evidence can reference child run/result IDs.
    • An evaluator failure exposes a bounded reason code and retry state.
    • A Goal does not keep iterating solely because completed child evidence is unreachable.
    • External-state verification and child receipts remain distinguishable:
      • “online version changed” is evidence;
      • it is not by itself proof that all quality gates passed.

    ---

    I. Current reproduction of the invisible-browser handoff problem

    During this follow-up, browser navigation to a public GitHub issue succeeded, but the snapshot reported:

    viewport: 0x0
    

    The automation context was not authenticated and exposed only a login link. The user could not be asked to authenticate in that invisible browser safely.

    This is current evidence for dashboard item 6. It does not establish a new ownership model, but it supports opening the focused telemetry/reproduction issue requested by the current dashboard.

    Useful telemetry would include:

    • browser context/lease ID;
    • visibility state;
    • viewport;
    • owning conversation;
    • whether user takeover is supported;
    • whether “Open in my browser” is available;
    • authentication handoff state.

    ---

    J. Intent-only terminal replies were indistinguishable from started work

    In the same session, the assistant twice produced terminal responses equivalent to:

    I will now open the issue and submit the comment.

    No browser or write operation had started before those terminal responses. The user had to ask:

    Did you do it?

    and then:

    What are you doing?

    This is partly model behavior, but the harness provided no authoritative operation state next to the terminal response:

    declared action: submit issue comment
    actual operation: none started
    assistant terminal state: completed response
    task state: unclear
    

    This is additional evidence for dashboard items 10 and 12:

    • response completion is not task completion;
    • natural-language future intent must not be the only task progress signal;
    • the user needs an authoritative projection showing whether an operation actually started.

    A product-level progress projection should derive from Runtime facts such as:

    not started
    running
    waiting for user/authentication
    completed
    failed
    interrupted
    

    It should not infer completion from assistant prose.

    ---

    Suggested routing against the current #4267 dashboard

    Evidence	Route
    Windows command sandbox unavailable after approved boundary	New focused Windows reproduction under item 1
    ACL-ledger mutex blocking filesystem workers	New focused Windows sandbox issue
    agent_list/agent_spawn identity mismatch	Separate issue permitted by item 9's current disposition
    Dirty parent blocking commit-isolated child worktree	New Agent orchestration/workspace issue
    Scheduled child result not linked to parent	New scheduled-execution provenance issue
    Impossible first-page SearchHistory cursor	New schema/runtime conformance issue
    Repeated terminal Agent Graph checkpoint	New Agent Graph supervisor issue
    Goal evaluator unable to consume child evidence	Goal/evidence integration issue
    Invisible unauthenticated 0x0 browser	Current reproduction for item 6
    Intent-only terminal replies with no operation	Additional evidence for items 10 and 12

    Priority recommendation

    1. Windows sandbox/ACL-ledger recovery.
    2. Durable child-run result/provenance across ScheduledTask, Agent Graph, and Goal.
    3. Catalog-to-invocation and SearchHistory schema conformance.
    4. Commit-isolated child worktree semantics.
    5. Browser visible-lease telemetry.
    6. Response/task terminal-state projection.

    The central new finding is that the harness can now discover tools and archive bounded results, but it still cannot reliably answer, across execution surfaces:

    Which run performed this work, what is its authoritative terminal state, where is its durable result, and which acceptance evidence belongs to it?
11. Astro-Han

    added

    trackingTracking or umbrella issueTracking or umbrella issue

    on Sep 17, 2026
12. github-actions

    added

    staleNo qualifying activity within the lifecycle policy windowNo qualifying activity within the lifecycle policy window

    on Oct 4, 2026
13. github-actions commented on Oct 4, 2026

    

    github-actionsbot

    on Oct 4, 2026 – with GitHub Actions

    More actions

    This issue has had no human activity for 30 days and has been marked stale. It will be closed in 30 days unless someone comments.

    If the issue is still current, please confirm it against the latest main and add any information that would help move it forward. Assigned issues and issues labelled pinned are exempt from this policy.
14. liugddx commented on Oct 8, 2026

    

    liugddx

    on Oct 8, 2026

    MemberAuthor

    More actions

    Status refresh against main@49e01b157. Keeping this open, because five rows still have no completed delivery:

    • Row 1 (managed Bash executable substrate): open. fix(runtime): allow bounded Apple Git startup #5266 (bounded Apple Git startup) is the current attempt for the Apple toolchain case. It is still under review and waiting on real CLT/Xcode Seatbelt evidence.
    • Row 3b (shell output lost before archiving): open, with fix(runtime): RuntimeEvent ledger is recovery-grade (WAL), not source-of-truth — write-path truncation blocks counterfactual replay #615.
    • Row 4 (structured public GitHub research): open. There is still no focused delivery issue.
    • Row 5 (Bypass and client capability boundary): resolved. Permission mode switch (Auto→Bypass) is not honored by the next turn #3349 was completed via fix(runtime): land permission switches before the next turn's first tool call (#3349) #3615, and enhancement(runtime): allow Auto mode to use tools currently restricted to Full Access on macOS #4012 via feat(desktop): authorize client capabilities in managed sessions #4143/fix(desktop): publish MCP tools through native capabilities #4490.
    • Row 6 (browser visible-lease): open. It still needs a focused reproduction issue.
    • Row 10 (completion versus delivery): investigation.

    #4452 (ArchiveRead convergence, referenced in row 3) closed as not planned, so row 3 has no remaining follow-up here. Once rows 1, 3b and 4 have their own issues or merged fixes, I'll close this tracker.
15. github-actions

    removed

    staleNo qualifying activity within the lifecycle policy windowNo qualifying activity within the lifecycle policy window

    on Oct 9, 2026