feat(agent-harness): fence designated client tool execution - #5697
Open
iscekic wants to merge 1 commit into
Open
feat(agent-harness): fence designated client tool execution#5697iscekic wants to merge 1 commit into
iscekic wants to merge 1 commit into
Conversation
This was referenced Aug 29, 2026
Contributor
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (4 files)
Reviewed by grok-4.6 · Input: 315.3K · Output: 20.8K · Cached: 596.1K Review guidance: REVIEW.md from base branch |
This was referenced Aug 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No new behavior — this change prepares device actions without enabling them in the product.
Summary
ClientToolCommandacceptsclaimClientToolandcompleteClientTool;ClientToolAuthorizersuppliesClientToolAuthoritythroughAuthoritySchema, including authenticated identity and original journal availability.Validation checks
IntentSchemaand rejects inconsistent grants, calls, or receipts before replay; revocation, journal loss, or incompatible capabilities also block replay.Canonical replay skips dispatch preparation and new reservations but retains authority and fingerprint checks, so committed waits survive later policy failures or budget exhaustion.
Files
services/agent-harness/src/client-tools.ts— adds command validation, scoped authentication before and after preparation, journal fingerprints, canonical replies, and structured rejections. Requires exactly one matching grant and attempt; validates ownership, context, input digest, definition version, generation, and immutable completion. Constructsclient_actionupdates for waits and reconciliation.commitDispatchaccepts an optionalExecutionGrantinside the existing scheduler transaction, committing the grant, linked attempt, policy, and executing state atomically.Each grant binds the client, account, conversation, context, input digest, tool version, and generation; existing backend callers continue without a grant.
Concurrent valid claims reuse the same committed grant rather than creating another attempt.
Files
services/agent-harness/src/dispatch.ts— persists the grant and links its identifier to the existing attempt before the compare-and-set transition to executing.clientToolandclientUnavailableextend the scheduler with orderedclient_actionwaits and receipt settlement for the originating client.Dispatch preparation reserves time before checks;
ExecutionGrant.expiresAtkeeps that deadline, interrupted preparation stays charged, and idle device waits consume no time.Stop cancels undispatched work; expired or interrupted grants require receipt reconciliation, including client reads, without transfer or reexecution.
Files
services/agent-harness/src/scheduler.ts— adds grant claims, validated immutable completions, and lifecycle notifications without a second scheduler. Persists background, offline, locked, gesture, unavailable, and reconciliation waits; clears client actions when they settle. Shares dispatch and settlement transitions, rechecks checkpoint scope, input digests, and call order, and keeps approval, permission-revision, and Stop gates. Reserves preparation before authorization and policy checks, bounds those checks, and retains the original grant deadline. Lost preparation retains its full reservation; failed checks and losing claims release only their own preparation. Only a committed grant takes the active lease. Accepts the original grant's validated receipt after expiry or Stop and preserves the actual outcome. Confirmed receipts resume waiting runs unless Stop blocks continuation; waits and uncertain outcomes continue to block later calls and runs.Tests: 1 test file added:
services/agent-harness/src/client-tools.test.ts(+1,326 lines). Covers SQLite claims, waits, receipts, replay, timing, Stop, corruption, crash recovery, and shared journal faults.Generated: 0 files changed.
Visual Changes
Visual Changes: N/A
Verification
Reviewer Notes
This description covers level 14 only, based on level 13.
Human steps
Recorded checks
The implementer recorded four passing scoped checks through
run-checks.sh. This description round did not rerun them.pnpm --filter @kilocode/agent-harness-worker exec vitest run src/client-tools.test.ts— passed on the local SQLite test Worker.oxlinton the four changed files — passed.oxfmt --checkon the four changed files — passed.git diff --checkon the four changed files — passed.Notes
E2E: bot-e2e — full backend, browser, iOS, and Android verification remains pending at the completed stack tip.
Stacked PRs — merge bottom to top. Each level shows only its own diff.
Runtime verification (E2E, user advocacy, simplify) runs on the tip PR over every level.
Every level keeps its own checks, its own bot review, and its own threads; each one is answered on its own PR.
Each level is its own deliverable: it builds and passes its own checks alone.
A finding on a level is repaired on that level, then carried upward with stack.sh forward.
shared-agent-harness-3bb0— chore(agent-harness): register workspaces and enforce CI boundaries #5632shared-agent-harness-3bb0-s2— feat(agent-harness): define portable domain and snapshots #5637shared-agent-harness-3bb0-s3— feat(agent-harness): define commands tools and permission policy #5639shared-agent-harness-3bb0-s4— feat(agent-harness): share client state and cursor recovery #5643shared-agent-harness-3bb0-s5— feat(agent-harness): persist command intents and execution receipts #5647shared-agent-harness-3bb0-s6— feat(db): add harness ingress grants and retirement fences #5655shared-agent-harness-3bb0-s7— feat(agent-harness): deliver legacy history and project durable text #5659shared-agent-harness-3bb0-s8— feat(agent-harness): authorize durable grants and registered clients #5662shared-agent-harness-3bb0-s9— feat(agent-harness): fence retirement and retry payload cleanup #5667shared-agent-harness-3bb0-s10— feat(agent-harness): persist authoritative state in SQLite #5675shared-agent-harness-3bb0-s11— feat(agent-harness): admit durable runs and revisioned commands #5678shared-agent-harness-3bb0-s12— feat(agent-harness): recover queued runs and stream checkpointed steps #5688shared-agent-harness-3bb0-s13— feat(agent-harness): resolve interactions and dispatch tools sequentially #5693shared-agent-harness-3bb0-s14— feat(agent-harness): fence designated client tool execution #5697 ← this PRshared-agent-harness-3bb0-s15— feat(agent-harness): synchronize durable snapshots and legacy history #5701shared-agent-harness-3bb0-s16— feat(agent-harness): reuse authorized invitations with durable replay #5704 (tip)