[chrisohearn]

The Jarvis inbox acknowledges every message with a full model run. On 2026-11-12 a long-lived acknowledger session acted on messages meant for Jarvis: it sent 19 messages as Jarvis, wrote the ledger 8 times and used a one-run approval. Each acknowledgement also costs a model call and about 10 s, and the queue backs up in bursts.

This PR adds a per-thread acknowledge-only mode. For a thread in the mode, the server completes each run itself with a written reply, Queued: `<first 120 characters, one line>` (the excerpt is in a code span with token-like strings redacted). No provider session opens, no tools run and no tokens are spent. The run emits the same run lifecycle and result events as a provider turn, so inbox subscriptions, relay and notify wake Jarvis unchanged.

The mode is not enabled anywhere. The coordinator enables it on the inbox after deploy and verifies that Jarvis still wakes.

Item 12 (revised): acknowledge-only inbox

Evidence (live DB, read-only)

• In the 48 h audit window there were 169 acknowledger runs, with a p90 time to reply of 285 s, bursts of 57 messages an hour and 24 queued at once.
• Today (since 2026-11-13T00:00Z), the baseline acceptance query returns: 135 runs, p90 request-to-reply 811 s, max 1,458 s, 133 provider turns, and 69 assistant replies not in the acknowledgement form.
• A real acknowledger run's events: run.created queued → run.updated starting → running → assistant node, message and turn item → attempt completed → run.updated waiting → checkpoint → run.updated completed.

Change

• Setting. acknowledgeOnlyThreadIds server setting (packages/contracts/src/settings.ts). It needs no migration, and a bad hand-edited entry drops alone.
• Hook. ProviderTurnStartService.start gains a 20-line hook. It runs before slash-command handling and before any session open. For an acknowledge-only thread it calls settleAcknowledgeOnlyRun in the new fork-only file orchestration-v2/AcknowledgeOnly.ts, which writes these events in one guarded commit: run.updated running, attempt and root node running, the assistant node, message.updated (assistant), the assistant_message turn item, attempt completed, run.updated completed, root node completed, and the provider-thread status.
  • Deliberate omissions: no provider turn, no waiting step and no end-of-turn checkpoint (the live acknowledger's checkpoint was missing anyway). The queue advances through the existing run.updated completed reactor.
• Tool. t3_thread_configure gains acknowledgeOnly, set alone. It requires a full-access caller (writesEnvironment) both to turn the mode on and to turn it off; read-only and auto callers are refused. Reading the thread's configuration reports acknowledgeOnly (optional in the result, so linked environments on other builds still decode).
• Service. ThreadManagementService gains acknowledgeOnly and setAcknowledgeOnly, so the thread toolkit needs no new dependency.
• Docs.
  • docs/jarvis/decisions/0009-jarvis-inbox.md is updated with what the mode does, its events, what gets acknowledged, who can change it, turning it off and its known limits.
  • docs/user/outside-agents.md and the docs/jarvis/GLOSSARY.md term are updated too.
• Notify race checked: none. A relay binding's scan cursor rewinds to the run's first run.updated, so a run that finishes in milliseconds is still relayed.

Tests

• AcknowledgeOnly.integration.test.ts uses the orchestrator, the effect worker and a fake provider adapter. Three messages queue before the worker starts. The test checks that:

  • they are acknowledged in send order;
  • each run's lifecycle is run.created queued → run.updated starting → running → completed;
  • no session opens and no provider turn runs;
  • each run's last assistant message is the acknowledgement, including the 120-character one-line excerpt;
  • McpEvents.observeEvent maps each completion to thread.run.result for that run id.

  The mode is turned on and off through AcknowledgeOnly.setAcknowledgeOnly while another thread id stays in the list, and the next message is then an ordinary provider turn. The test fails with the hook disabled.

• core.test.ts (existing configure access test, extended) checks that read-only and auto clients are refused both ways, that full access sets and clears the mode, and that the read shows it.

• settings.test.ts (existing hand-edit test, extended) checks that bad entries drop alone.

• Locally, under the round-four resource rule (shared lock, --maxWorkers=2): server and contracts typecheck, plus 7 focused server test files (161 tests) and the contracts settings test. CI is the full gate.

Acceptance check (read-only; set since to the time the mode was enabled on the inbox)

sqlite3 -readonly -header -column ~/.t3/userdata/statev2.sqlite <<'SQL'
WITH inbox(id) AS (SELECT 'mcp:launch:be52150eaa983a46dcfa1e2bcdbfcfc1fc10f66d3d303f80b59c341fa1c87c23'),
since(t) AS (SELECT '<enabled-at ISO time>'),
runs AS (
  SELECT r.run_id, r.status,
    (julianday(json_extract(r.payload_json, '$.completedAt')) - julianday(r.requested_at)) * 86400 AS reply_s
  FROM orchestration_v2_projection_runs r, inbox, since
  WHERE r.thread_id = inbox.id AND r.requested_at >= since.t),
done AS (SELECT reply_s, row_number() OVER (ORDER BY reply_s) AS n, count(*) OVER () AS total
  FROM runs WHERE status = 'completed')
SELECT
  (SELECT count(*) FROM runs) AS runs,
  (SELECT count(*) FROM done) AS completed,
  (SELECT round(min(reply_s), 3) FROM done WHERE n >= 0.9 * total) AS p90_request_to_reply_s,
  (SELECT round(max(reply_s), 3) FROM done) AS max_request_to_reply_s,
  (SELECT count(*) FROM orchestration_v2_projection_provider_turns t
     JOIN orchestration_v2_projection_run_attempts a ON a.attempt_id = t.run_attempt_id
     JOIN runs ON runs.run_id = a.run_id) AS provider_turns,
  (SELECT count(*) FROM orchestration_v2_projection_messages m JOIN runs ON m.run_id = runs.run_id
     WHERE m.role = 'assistant'
       AND json_extract(m.payload_json, '$.text') NOT LIKE 'Queued: %'
       AND json_extract(m.payload_json, '$.text') <> 'Queued.') AS non_ack_replies;
SQL

Pass:

• completed = runs;
• provider_turns = 0 and non_ack_replies = 0;
• max_request_to_reply_s < 1 when the queue is quiet, otherwise about 1 s per queued message ahead of it;
• jq .acknowledgeOnlyThreadIds ~/.t3/userdata/settings.json lists the inbox;
• bridge_status shows lastSuccessfulEventDeliveryAt advancing after the enable, which means Jarvis still wakes.

Review fixes (independent review of record, 7b11d3e)

• P2, restart hold. ProviderRuntimeRecoveryService no longer marks an acknowledge-only thread's queued runs queueHeld at shutdown or startup, and it releases a hold left from before. The restart case is added to the existing "recovers $0 work after restart" table test.
• Excerpt. The reply is now neutral, Queued: `<excerpt>` . The excerpt sits in a code span, so no Markdown link, image or autolink renders, and backticks become '. Token-like strings (32+ characters, and the update guard's known prefixes) become [redacted]. The integration test covers an image, a link, a backtick and a ghp_ token.
• Atomic toggle. ThreadManagementService.setAcknowledgeOnly runs under a one-permit lock. withSettingsSnapshot can't be used here, because it holds the settings write lock that updateSettings takes.
• Handoffs. Context handoffs addressed to the acknowledged run are marked superseded in the same commit as the reply. Handoffs carried forward to later runs are untouched.
• Conflicts. t3_thread_configure now branches inside the existing write handler through a new McpToolAccess.requireFullAccess (the writesEnvironment check). Upstream lines are no longer re-indented: handlers.ts goes from 122 changed lines to about 40.

Notes for the merger

• Migration id: none.
• agentContextBudget.json mcpToolListJsonBytes is provisional (this PR adds 133 bytes on top of the tip's 57,928; still 58,061 after the review fixes). Other round-four PRs change tool text too, so re-measure at merge.
• Evals not run. AGENTS.md asks for the mcp-tool-use eval after tool-text changes. This worktree has no eval API keys, and the runs would spend money. The change only adds an optional admin parameter and one description sentence.
• Test mocks. Partial ThreadManagementService mocks that read t3_thread_configure need acknowledgeOnly (three updated here). Expect the same on upstream syncs.
• Known limits (recorded in 0009):
  • the thread still needs a configured, enabled provider;
  • a queue already held when the mode is turned on needs one resume;
  • enabling it does not detach an attached provider session.

Model: Claude Opus 5.5 (Claude Code harness in T3 Code).

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary: ❌ Failed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	❌ Failed 2026-11-13T04:40:08.833455Z We couldn’t complete this review. Comment @codex review to try again.	7b11d3e	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[chrisohearn]

Independent Claude Opus review of 7b11d3e (review of record)

Read-only review of the diff, the run-start path, McpEvents and McpEventRelay, recovery, and PRs #90, #91 and #94. I ran AcknowledgeOnly.integration.test.ts under the heavy lock: 1/1 passed. Merge state at review: MERGEABLE/UNSTABLE. Build and Typecheck, Test and Test Web 2 were pending, and Agent context budget had failed.

P2

• Restart mid-queue holds the inbox. This is base behaviour, not a regression, but this mode is meant to fix it. ProviderRuntimeRecoveryService.ts:420-442 sets queueHeld: true on queued runs at shutdown and startup reconcile. Only web or mobile user messages release a hold (Orchestrator.ts:7429-7440); MCP sends do not. After a deploy restart, the ack-only inbox appears to stay silent, and Jarvis stops waking, until someone resumes the queue. There is no double ack: writeIfRunCurrent with expectedStatus: "starting" plus derived ids (AcknowledgeOnly.ts:64-68,156-162) make a replayed effect a no-op. Suggested fix: exempt ack-only threads from the hold or auto-resume them. At minimum, add this to the 0009 known limits and add a restart test.
• Merge conflicts. #91 and #94 both edit the t3_thread_configure predicate, result struct, description and params (thread/handlers.ts:240-315, thread/tools.ts:187-207). This PR re-indents the whole block, so textual conflicts are certain. Semantically, once #91 lands, the ack branch must also reject autoReview sent alongside acknowledgeOnly (handlers.ts:253-257); otherwise autoReview is silently dropped. agentContextBudget.json conflicts with all three PRs; re-measure.
• The Agent context budget check fails: mcpToolListJsonBytes 57258 -> 57391 (+133). The mcp-tool-use evals were not run. Merging needs a cut, or a maintainer's agent-context-increase label.

P3

• Excerpt (AcknowledgeOnly.ts:41-45). It is bounded: 120 code points, whitespace collapsed to one line, fixed prefix. But it relabels sender text as agent-authored output (createdBy: "agent", creationSource: "provider") and makes it the run's result text: assistant text and the relay resultExcerpt (McpEventRelay.ts:308). There is no secret masking and no Markdown escaping, so ![](url) renders. Array.from can also split grapheme clusters. Consider a code span and a token-pattern mask.
• setAcknowledgeOnly (AcknowledgeOnly.ts:27-39) does an unlocked read-modify-write on settings, so two toggles at once on different threads can lose one.
• Likely: the hook (ProviderTurnStartService.ts:461) returns before handoff delivery. A ready context handoff aimed at an acknowledged run (a provider switch or side chat) is never delivered, and isPendingForRun will not pick it up after the mode is turned off.
• At restart, a starting run whose message is not a retryable user message is cancelled, not acknowledged. The wake still fires as thread.run.result with state cancelled. The window is tiny.
• The settings:write RPC scope can also set acknowledgeOnlyThreadIds (settings.ts:1969); this is documented. The hard-coded "Queued for Jarvis" text is odd in a generic per-thread mode.

Checked, no issue found:

• (a) Same run.updated events through the same sink. observeEvent (subscriptions and webhooks) and the relay key only on status and runId. A relay binding's cursor starts at the run's first sequence minus one (McpEventRelay.ts:432-435), so a run that finishes in milliseconds is still relayed.
• (d) either picks one access rule per call. writesEnvironment applies assertNotLinked and assertFullAccess for both on and off.
• (e) Settings are re-read on every start, and the ack path never holds the queue.
• (f) Freeze holds the queue via thread.stop, so the hook is never reached on a frozen thread. Snooze-respect is send-side only.

Verdict: no blocking findings

[chrisohearn]

Independent delta review of c94302d (review of record, follows 7b11d3e review)

Read-only diff check: blobless clone, git range-diff 7eddc7fc..7b11d3e f0e6e4a325..c94302d. No tests run. Commit 1 changed only in the budget numbers; commit 2 holds the review fixes.

1. Restart: ProviderRuntimeRecoveryService.ts:425-448 runs in the one reconcileProjection used for startup and shutdown. holdQueue is false only when the thread is in acknowledgeOnlyThreadIds, and a failed settings read falls back to holding. Normal threads take the same condition and queueHeld: true as before. The skip of an existing hold depends on holdQueue, so older holds are re-emitted as queueHeld: false. The test row queued-acknowledge-only asserts that the queue is not held. It starts from an unheld run, so I checked the release of an older hold by reading the code only.
2. Reply: \s+ collapses every line terminator, including U+2028 and U+2029. Every U+0060 becomes ', so no backtick, and no run of backticks, can close the span. Redaction runs before the 120-code-point cut, and an empty excerpt gives Queued.. P3: the sk-, AKIA and ASIA prefixes have no word boundary, so the redaction over-matches (task-list becomes ta[redacted]). This only hides extra text.
3. Lock: Semaphore.make(1) wraps only setAcknowledgeOnly. That calls getSettings/updateSettings, which never call back into it, so there is no nested or reentrant permit and no deadlock. withPermits releases on failure and on interrupt.
4. Handoffs: context-handoff.updated with status superseded goes into the same writeIfRunCurrent batch as the completion, for handoffs whose targetRunId === run.id. Side-chat handoffs are outside handoffs and stay ready. This is minor and matches the documented carry-forward.
5. The prefix is neutral (Queued: ), and the docs match.
6. handlers.ts against f0e6e4a shows additions only, with no re-indent. requireFullAccess matches the writesEnvironment local check: orchestratingCaller, then assertNotLinked, then assertFullAccess. It now runs inside writesThread, so the local checks are stricter than before. The linked-environment pre-check becomes writingCaller, but the peer still refuses linked callers, so authority is not widened.
7. Budget: mcpToolListJsonBytes 57928 -> 58061 (+133).
   At review: MERGEABLE/UNSTABLE, with every check pending.

Verdict: no blocking findings

[chrisohearn]

Maintainer decision on the agent-context budget, from the round-four coordinator: approved with the agent-context-increase label. +133 bytes (57,928 to 58,061) for the optional acknowledgeOnly parameter on t3_thread_configure. The independent review and delta review (c94302d) found no blocking findings. Paid evals waived: spending needs Chris's go-ahead.