Skip to content

[codex] Reduce iMessage turn setup latency#96199

Closed
omarshahine wants to merge 8 commits into
mainfrom
omarshahine/performance
Closed

[codex] Reduce iMessage turn setup latency#96199
omarshahine wants to merge 8 commits into
mainfrom
omarshahine/performance

Conversation

@omarshahine

@omarshahine omarshahine commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

What Problem This Solves

Tracks the iMessage source-reply latency investigation from #96148 and packages the first two concrete improvements from the tracing work:

  • avoid rebuilding selected plugin tool runtimes during an agent turn when the gateway-active registry already contains the required tool plugins
  • keep the late bundled MCP/LSP tool-policy filter for authorization, but stop surfacing its audit as a duplicate primary info-level tool-policy pass

The live traces showed gateway startup/prewarm could reuse the runtime registry, but per-turn tool construction still re-registered expensive external plugins such as travel-hub and porsche-connect-cli when the turn workspace differed from the gateway workspace.

Why This Change Was Made

The plugin tool resolver matched registry reuse against the turn workspace. In gateway mode, plugin metadata and runtime registries are process-stable, so the active gateway registry workspace is the canonical workspace for deciding whether the already-loaded registry can satisfy a scoped tool request. This PR makes plugin tool lookup use that active workspace only for existing-registry reuse; fresh standalone loads still use the request context.

This also adds the tracing and iMessage reliability fixes used to gather the data:

  • iMessage performance phase callbacks for receive, dispatch, provider/model prep, first model event, and completion
  • safer iMessage monitor startup when the watch subscription replays before subscribe() returns
  • client close-reason propagation so unexpected monitor exits reject instead of looking like intentional stops
  • auth profile snapshot reuse for prepared runtime turns
  • scoped active plugin registry reuse across startup, runtime plugin prewarm, and plugin tool lookup

User Impact

Users should see less avoidable setup work before an iMessage reply turn starts, especially with enabled external tool plugins. Verbose traces should also be easier to read because the secondary bundled-tool policy audit no longer appears as another primary hot-path policy pass.

This does not claim to fix the separate startup warmup stall observed in the latest live run: model warmup still stalled for roughly 116s before post-ready plugin prewarm in the narrowed config. That remains tracked in #96148.

Evidence

  • node scripts/run-vitest.mjs extensions/imessage/src/status.test.ts extensions/imessage/src/monitor.last-route.test.ts extensions/imessage/src/monitor.watch-subscribe-retry.test.ts
  • node scripts/run-vitest.mjs src/agents/runtime-plugins.test.ts src/agents/runtime-plugins.registry-reuse.test.ts src/plugins/loader.runtime-registry.test.ts
  • node scripts/run-vitest.mjs src/plugins/tools.optional.test.ts
  • node scripts/run-vitest.mjs src/plugins/tools.optional.test.ts src/agents/embedded-agent-runner/effective-tool-policy.test.ts src/agents/agent-bundle-mcp-tools.request-boundary.test.ts
  • node scripts/run-vitest.mjs src/agents/runtime-plugins.test.ts src/agents/runtime-plugins.registry-reuse.test.ts src/plugins/loader.runtime-registry.test.ts extensions/imessage/src/status.test.ts extensions/imessage/src/monitor.last-route.test.ts extensions/imessage/src/monitor.watch-subscribe-retry.test.ts
  • pnpm tsgo:prod
  • git diff --check
  • .agents/skills/autoreview/scripts/autoreview --mode local --prompt "Review the current OpenClaw performance/tracing patch. Focus on plugin runtime registry reuse, bundled tool-policy audit level, iMessage monitor/client changes, and auth profile snapshot reuse. Treat the full dirty tree as intended PR scope."

Live diagnostic evidence:

  • Before the final plugin-tool patch, narrowed live config still re-registered travel-hub and porsche-connect-cli during the message turn and the embedded run completed in 8445ms.
  • After the patch, source gateway startup with the narrowed config reached post-ready runtime plugin prewarm at 353ms and loaded 149 plugins / 6 attempted in 311.8ms.
  • A fresh inbound iMessage turn did not arrive during the final live window before shutdown, so per-turn no-re-registration proof is still pending on this PR branch.

Tracking issue: #96148

@openclaw-barnacle openclaw-barnacle Bot added docs Improvements or additions to documentation channel: imessage Channel integration: imessage scripts Repository scripts agents Agent runtime and tooling extensions: codex size: XL labels Jun 23, 2026
@omarshahine omarshahine mentioned this pull request Jun 23, 2026
Closed
6 tasks
@openclaw-barnacle openclaw-barnacle Bot added the maintainer Maintainer-authored PR label Jun 23, 2026
@omarshahine

omarshahine commented Jun 23, 2026

Copy link
Copy Markdown
Contributor Author

Live PR-branch test update from /tmp/openclaw-runtime-reuse-pr96199-test.log:

  • Source gateway reached runtime plugin prewarm: loaded 149 plugin(s) (6 attempted) in 461.1ms; agent runtime plugins pre-warmed in 530ms.
  • Startup still hit the separate warmup stall: startup model warmup timed out after 5000ms, followed by the known liveness warning path.
  • The attempted fresh iMessage send was not a valid inbound turn for this monitor: dropped inbound message ... reason="from me" ... created_at=2026-06-23T23:29:11.875Z. Because the local Messages account authored it, the iMessage plugin intentionally ignored it.
  • A recovered iMessage session did finish and reply ok, but it was restart-recovery/compaction work rather than the fresh external-inbound test: embedded run f98c567e-5095-42fb-8d66-9123ac2d9057 completed in 8489ms, while its compaction later took 139294ms.
  • Important remaining bottleneck: plugin re-registration still occurs outside the startup/prewarm path, including compaction/session/provider paths. Examples in this run include travel-hub / porsche-connect registrations around 16:28:27, 16:28:47, 16:28:59, 16:29:21, and 16:30:31.

Conclusion: PR #96199 improves and instruments the path, but live testing shows it does not fully eliminate plugin runtime rebuilds. Next patch should target the compaction/session/provider registry loader paths, not only plugin-tool resolution.

@omarshahine

omarshahine commented Jun 23, 2026

Copy link
Copy Markdown
Contributor Author

Follow-up pushed to PR #96199: d3c3562fcc (perf: reuse gateway provider hooks for turn workspaces).

What changed:

  • Added an explicit allowGatewayRegistryWorkspaceReuse provider-hook lookup flag.
  • Embedded agent attempts set the flag because their effectiveWorkspace can be a turn workspace while provider/plugin runtime hooks should come from the gateway-active registry when it is already gateway-bindable.
  • Provider hook lookup only rewrites to the active plugin workspace when both conditions hold: the caller opted in, and the active registry is gateway-bindable.
  • Added regressions for the intended reuse and for the two unsafe cases: no opt-in, and default-mode active registries.

Proof:

  • node scripts/run-vitest.mjs src/plugins/provider-runtime.test.ts src/plugins/providers.test.ts src/plugins/providers.runtime.consult-current-snapshot.test.ts
  • pnpm tsgo:prod
  • git diff --check
  • Autoreview initially found the unsafe cross-workspace heuristic; after threading the explicit opt-in, final autoreview returned clean with no accepted/actionable findings.

This targets the provider-hook side of the post-startup re-registration seen in the live PR-branch run. A fresh live test from a non-local iMessage sender is still needed for wall-clock proof.

@omarshahine

omarshahine commented Jun 24, 2026

Copy link
Copy Markdown
Contributor Author

Clean steady-state PR-branch iMessage sample from 2026-06-23 16:59 PT:

  • Gateway already up and idle before the inbound message.
  • Diagnostic end-to-end: message processed ... duration=11699ms.
  • Dispatch duration: 11678ms.
  • Embedded run: runId=2cffc27b-ca74-406d-8034-c11329337a55, durationMs=11167.
  • Hot-path setup after the PR:
    • runtime_plugins: reached at 628.6ms, delta 2.0ms.
    • model_resolution: delta 138.8ms.
    • auth: delta 5.9ms.
    • context_engine: delta 2.3ms.
    • attempt_dispatch: delta 3.2ms.
    • agent run started at 956.6ms.
    • model call starting at 1110.6ms.
    • turn accepted at 1122.4ms.
    • first model event at 2672.5ms.
    • message tool execution started at 11319.3ms.

Conclusion: the PR removed the repeated plugin/runtime setup from the steady-state hot path. The clean remaining wall clock is dominated by the provider/model turn: ~1.55s from turn accepted to first event, then ~8.65s until the message tool call.

@omarshahine omarshahine mentioned this pull request Jun 24, 2026
Closed
@clawsweeper

clawsweeper Bot commented Jun 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Codex review: found issues before merge. Reviewed June 23, 2026, 10:30 PM ET / 02:30 UTC.

Summary
The PR adds iMessage/Codex latency tracing and source-reply robustness changes, plus runtime plugin, provider-hook, and plugin-tool registry reuse to reduce iMessage turn setup latency.

PR surface: Source +814, Tests +1095, Docs 0, Other 0. Total +1909 across 37 files.

Reproducibility: yes. with caveat: the linked issue and PR comments provide live iMessage timing samples and the source paths are clear, but this read-only review did not run a fresh live iMessage reproduction.

Review metrics: 3 noteworthy metrics.

  • PR size: +2039/-130 across 37 files. The branch crosses iMessage, Codex, agent runtime, plugin loader, provider hooks, SDK surface, docs, and scripts, so review needs surface-by-surface ownership rather than one broad pass.
  • Cross-workspace reuse paths: 3 paths changed. Runtime plugin loading, provider-hook lookup, and plugin-tool lookup each reuse active gateway state across workspace boundaries and need independent compatibility proof.
  • Plugin SDK surface: 1 export added; API budget +2 public/+2 function exports. Public plugin SDK changes are compatibility-sensitive and should be deliberate rather than incidental to a latency investigation branch.

Stored data model
Persistent data-model change detected: persistent cache schema: src/agents/runtime-plugins.registry-reuse.test.ts, persistent cache schema: src/plugins/loader.runtime-registry.test.ts, persistent cache schema: src/plugins/runtime/standalone-runtime-registry-loader.ts, serialized state: src/agents/auth-profiles/session-override.test.ts, serialized state: src/agents/auth-profiles/session-override.ts, unknown-data-model-change: src/agents/auth-profiles/session-override.test.ts. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #96148
Summary: Issue 96148 remains the canonical iMessage source-reply latency tracker; this PR is a broad candidate fix, while PR 96231 is a narrower open candidate for the safer runtime-registry subset.

Members:

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🐚 platinum hermit
Patch quality: 🧂 unranked krab
Result: blocked by patch quality or review findings.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

  • Rebase or continue through the narrower compatible registry-reuse PR 96231.
  • [P2] Remove provider-hook and plugin-tool cross-workspace reuse, or add compatibility-key tests and upgrade proof for mismatched workspaces/configs.
  • Keep the live timing evidence on issue 96148 and split unrelated tracing/SDK changes into separately reviewable PRs.

Risk before merge

  • [P1] Cross-workspace registry reuse can select provider hooks or plugin tools from the gateway workspace for turns whose config, plugin roots, installed records, or auth/provider routing belong to a different workspace.
  • [P1] The runtime plugin path can fresh-load startup plugins from the active gateway workspace on a cache miss instead of falling back to the caller workspace, which is the exact compatibility property the narrower successor PR restores.
  • [P1] The PR expands public Plugin SDK surface and changes Codex/iMessage source-reply behavior in the same XL branch, making ownership and upgrade review harder than the safe runtime-registry subset.
  • [P1] The branch is draft and currently conflicting with main, so the reviewed diff cannot be treated as a clean landing candidate until rebased and re-reviewed.

Maintainer options:

  1. Split to the compatible reuse subset (recommended)
    Rebase this work or continue through PR 96231 so startup-scoped registry reuse only returns an already-compatible registry and all misses load from the caller workspace.
  2. Prove provider and tool reuse separately
    Keep provider-hook and plugin-tool cross-workspace reuse out of the main branch until tests cover mismatched workspace roots, configs, plugin scopes, provider hooks, and fallback loads.
  3. Pause the broad draft
    If the narrow PR owns the safe performance win, close or park this XL draft and preserve its live traces on issue 96148 for follow-up work.

Next step before merge

  • [P2] Maintainers need to decide whether to close or split the broad draft in favor of PR 96231 and what compatibility contract is acceptable for provider/tool cross-workspace reuse.

Security
Cleared: The diff does not add dependencies, lockfile changes, workflow permissions, downloaded code, or secret-handling expansion; the provider/plugin concerns are compatibility and routing risks rather than a concrete security regression.

Review findings

  • [P1] Keep fallback loads on the caller workspace — src/agents/runtime-plugins.ts:55-58
  • [P1] Gate provider-hook reuse on a compatible registry — src/plugins/provider-hook-runtime.ts:148-155
  • [P2] Prove tool registry compatibility before switching workspaces — src/plugins/tools.ts:904-916
Review details

Best possible solution:

Land or review the narrow cache-key-compatible startup registry reuse path in #96231, keep #96148 as the tracker, and defer provider-hook/plugin-tool cross-workspace reuse until it has explicit compatibility proof or maintainer approval.

Do we have a high-confidence way to reproduce the issue?

Yes, with caveat: the linked issue and PR comments provide live iMessage timing samples and the source paths are clear, but this read-only review did not run a fresh live iMessage reproduction.

Is this the best way to solve the issue?

No: the broad branch is a useful investigation artifact, but the best merge path is a narrower compatible registry-reuse PR plus separate proof for provider/tool reuse.

Full review comments:

  • [P1] Keep fallback loads on the caller workspace — src/agents/runtime-plugins.ts:55-58
    When startupPluginIds is present, this rewrites loadOptions.workspaceDir to the active gateway workspace before calling ensureStandaloneRuntimePluginRegistryLoaded. If the active registry is missing or incompatible, that loader falls through to loadOpenClawPlugins with this rewritten workspace, so an agent turn can fresh-load startup plugins from the gateway workspace instead of its own workspace. Keep reuse as an already-compatible cache hit and fall back to the original caller workspace on miss.
    Confidence: 0.89
  • [P1] Gate provider-hook reuse on a compatible registry — src/plugins/provider-hook-runtime.ts:148-155
    The opt-in only checks that the active registry is gateway-bindable before switching provider-hook lookup to the active workspace. It does not prove the active registry matches the requested config, plugin scope, provider catalog, or workspace cache key, so a turn workspace with different plugin/provider setup can receive gateway-workspace hooks and auth/profile behavior. Use the same compatibility-key reuse contract as the startup registry path or keep provider hooks on the caller workspace.
    Confidence: 0.84
  • [P2] Prove tool registry compatibility before switching workspaces — src/plugins/tools.ts:904-916
    This makes tool lookup probe channel and active registries under the active gateway workspace before proving that registry matches the caller's plugin load options. A turn workspace with different installed tools or plugin config can get stale or wrong tool registrations, even though the fallback load later uses the original options. Restrict this to a cache-key/scope-compatible hit or remove the cross-workspace tool reuse path.
    Confidence: 0.81

Overall correctness: patch is incorrect
Overall confidence: 0.84

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against d42b86421969.

Label changes

Label changes:

  • add P2: The PR targets a real iMessage/Codex latency problem with limited blast radius, but it is not an emergency and needs maintainer review before merge.
  • add merge-risk: 🚨 compatibility: The diff changes runtime/plugin registry reuse across workspace boundaries and can affect existing plugin installs, config, and upgrade behavior.
  • add merge-risk: 🚨 message-delivery: The branch also changes iMessage/Codex source-reply and message-tool-only behavior, where wrong runtime/tool selection can suppress or misroute a delivered reply.
  • add merge-risk: 🚨 auth-provider: Provider-hook lookup can now reuse gateway-workspace provider hooks for turn workspaces, which can alter provider routing, auth-profile behavior, and model hook selection.
  • add proof: sufficient: Contributor real behavior proof is sufficient. PR comments include after-fix live iMessage logs with inbound/outbound rows and phase timings showing the repeated runtime setup removed from the steady-state hot path.
  • add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🐚 platinum hermit and patch quality is 🧂 unranked krab.
  • add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (logs): PR comments include after-fix live iMessage logs with inbound/outbound rows and phase timings showing the repeated runtime setup removed from the steady-state hot path.

Label justifications:

  • P2: The PR targets a real iMessage/Codex latency problem with limited blast radius, but it is not an emergency and needs maintainer review before merge.
  • merge-risk: 🚨 compatibility: The diff changes runtime/plugin registry reuse across workspace boundaries and can affect existing plugin installs, config, and upgrade behavior.
  • merge-risk: 🚨 auth-provider: Provider-hook lookup can now reuse gateway-workspace provider hooks for turn workspaces, which can alter provider routing, auth-profile behavior, and model hook selection.
  • merge-risk: 🚨 message-delivery: The branch also changes iMessage/Codex source-reply and message-tool-only behavior, where wrong runtime/tool selection can suppress or misroute a delivered reply.
  • rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🐚 platinum hermit and patch quality is 🧂 unranked krab.
  • status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (logs): PR comments include after-fix live iMessage logs with inbound/outbound rows and phase timings showing the repeated runtime setup removed from the steady-state hot path.
  • proof: sufficient: Contributor real behavior proof is sufficient. PR comments include after-fix live iMessage logs with inbound/outbound rows and phase timings showing the repeated runtime setup removed from the steady-state hot path.
Evidence reviewed

PR surface:

Source +814, Tests +1095, Docs 0, Other 0. Total +1909 across 37 files.

View PR surface stats
Area Files Added Removed Net
Source 24 936 122 +814
Tests 11 1100 5 +1095
Docs 1 1 1 0
Config 0 0 0 0
Generated 0 0 0 0
Other 1 2 2 0
Total 37 2039 130 +1909

What I checked:

  • Live PR state: PR 96199 is open, draft, labeled maintainer/channel: imessage/extensions: codex/size: XL, and GitHub reports mergeable=CONFLICTING with +2039/-130 across 37 files. (d3c3562fccd7)
  • Runtime plugin fallback uses active workspace: The PR changes startup-scoped runtime plugin loads to use the active gateway workspace before calling the standalone loader, so a cache miss can load from the gateway workspace instead of the caller workspace. (src/agents/runtime-plugins.ts:55, d3c3562fccd7)
  • Current loader loads on miss: Current main's standalone runtime loader falls through to loadOpenClawPlugins with the supplied loadOptions after no compatible loaded registry is found. (src/plugins/runtime/standalone-runtime-registry-loader.ts:74, d42b86421969)
  • Provider-hook reuse bypasses cache-key compatibility: The PR rewrites provider-hook lookup to the active gateway workspace whenever the caller opts in and the active registry is gateway-bindable, then probes loaded registries by workspace rather than by the requested config/plugin cache key. (src/plugins/provider-hook-runtime.ts:148, d3c3562fccd7)
  • Plugin-tool lookup rewrites workspace before registry probes: The PR checks channel and active tool registries under the active gateway workspace before the fallback standalone load returns to the caller's original loadOptions. (src/plugins/tools.ts:904, d3c3562fccd7)
  • Current main registry guard: Current main requires the requested workspace to match the active registry workspace unless the active-surface compatibility path receives loadOptions and passes cache-key checks. (src/plugins/active-runtime-registry.ts:95, d42b86421969)

Likely related people:

  • steipete: History shows substantial recent work around plugin runtime registry preservation, provider-hook guards, plugin tools, and iMessage test/refactor surfaces. (role: recent area contributor; confidence: high; commits: 067f158b74ed, 43cc92dc07ab, 725cbcc36246; files: src/plugins/provider-hook-runtime.ts, src/plugins/tools.ts, src/plugins/runtime/standalone-runtime-registry-loader.ts)
  • vincentkoc: History shows recent provider-hook seam work, plugin loader scope work, Codex auth/runtime work, and iMessage monitor retry work adjacent to this PR's surfaces. (role: recent adjacent owner; confidence: high; commits: a7436c8b4a93, 6a189eec0b1c, f1cc8f0cfc7c; files: src/plugins/provider-hook-runtime.ts, src/plugins/loader.ts, extensions/codex/src/app-server/run-attempt.ts)
  • Takhoffman: History ties this handle to plugin tool registry reload and iMessage default-account/config behavior, both relevant to workspace/config-sensitive runtime reuse. (role: adjacent compatibility contributor; confidence: medium; commits: 102e313d55f5, 36ac9224cc92, 4f5f1fa724a1; files: src/plugins/tools.ts, extensions/imessage/src/status.test.ts, extensions/imessage/src/monitor/monitor-provider.ts)
  • gumadeiras: History shows runtime registry compatibility and snapshot-load stabilization work in the same plugin registry compatibility area. (role: introduced adjacent registry compatibility helpers; confidence: medium; commits: ee7f5825c85e, fd0aac297c96, 78ac1184274e; files: src/plugins/active-runtime-registry.ts, src/plugins/loader.ts, src/plugins/runtime/standalone-runtime-registry-loader.ts)
What the crustacean ranks mean
  • 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
  • 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
  • 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
  • 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
  • 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
  • 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
  • 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works
  • ClawSweeper keeps one durable marker-backed review comment per issue or PR.
  • Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
  • A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
  • PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
  • Maintainers can also comment @clawsweeper review to request a fresh review only.
  • Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
  • Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
  • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

@clawsweeper clawsweeper Bot added proof: sufficient ClawSweeper judged the real behavior proof convincing. rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: ⏳ waiting on author ClawSweeper has contributor-facing work open and is waiting for author action. P2 Normal backlog priority with limited blast radius. merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. merge-risk: 🚨 message-delivery 🚨 May drop, duplicate, misroute, suppress, or wrongly target messages. merge-risk: 🚨 auth-provider 🚨 May break OAuth, tokens, provider routing, model choice, or credentials. labels Jun 24, 2026
@omarshahine

omarshahine commented Jun 25, 2026

Copy link
Copy Markdown
Contributor Author

@/var/folders/ks/54l0_v5j441gbf_8nbz9kgb80000gn/T/tmp.Q0LIOYEchk

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

agents Agent runtime and tooling channel: imessage Channel integration: imessage docs Improvements or additions to documentation extensions: codex maintainer Maintainer-authored PR merge-risk: 🚨 auth-provider 🚨 May break OAuth, tokens, provider routing, model choice, or credentials. merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. merge-risk: 🚨 message-delivery 🚨 May drop, duplicate, misroute, suppress, or wrongly target messages. P2 Normal backlog priority with limited blast radius. proof: sufficient ClawSweeper judged the real behavior proof convincing. rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. scripts Repository scripts size: XL status: ⏳ waiting on author ClawSweeper has contributor-facing work open and is waiting for author action.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@omarshahine