Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [RFC] Durable next-turn injections and agent turn preparation hooks [1 pull requests, 1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#71733•Fetched 2026-04-26 05:09:09
View on GitHub
Comments
1
Participants
1
Timeline
2
Reactions
0
Author
100yenadmin100yenadmin
Participants
100yenadmin100yenadmin
Timeline (top)
commented ×1cross-referenced ×1

Add a host-owned durable queue for plugin next-turn injections plus a typed agent_turn_prepare hook so plugins can schedule future prompt additions with exactly-once semantics.

This is proposed SDK surface, not currently implemented API.

Root Cause

Plan Mode approval acceptance, revision, question answering, nudges, and subagent follow-ups must affect a future run exactly once. before_prompt_build can add current-turn context, but it is not durable enough and should not become a pending interaction queue.

The same primitive is useful for plugins that receive an approval, event, timer, channel callback, CI result, ticket update, or memory selection outside the current model call and need to feed the next turn safely.

Fix Action

Fixed

PR fix notes

PR #71731: docs: add Plan Mode plugin host hook RFC

Description (problem / solution / changelog)

Summary

This PR is a maintainer RFC package for making Plan Mode a first-class bundled plugin without merging the large host patch from #71676.

  • Problem: #71676 proves Plan Mode behavior, but it embeds the feature across session state, gateway patching, agent turn preparation, pending injections, tool policy, commands, Control UI, agent events, scheduler/cron, heartbeat prompts, docs, QA, and channel flows.
  • Why it matters: maintainers prefer a plugin path. A plugin port cannot reach 100% parity unless OpenClaw first exposes generic host seams in the plugin SDK.
  • What changed: added an RFC packet, public index page, six issue-sized RFC threads, current-SDK gap research, reusable plugin matrices, a #71676 entry-point coverage map, and fixture-test expectations for a future implementation PR.
  • What did NOT change: this PR intentionally does not implement hooks, Plan Mode behavior, prompts, tools, UI cards, session fields, scheduler changes, or runtime SDK APIs.

RFC Status Warning

This is proposed SDK design, not implemented SDK reference. The docs now include explicit warning callouts, and the public page has been moved out of SDK reference into a dedicated Plugin design RFCs nav group.

RFC Decision Threads

  • #71732 — Plugin session extensions and patch actions
  • #71733 — Durable next-turn injections and agent turn preparation hooks
  • #71734 — Trusted tool policy stage and plugin tool metadata
  • #71735 — Scoped plugin commands, trusted command ownership, and continuation
  • #71736 — Control UI plugin contribution slots
  • #71737 — Agent events, run context, scheduler lifecycle, and heartbeat contributions

The issue bodies have been expanded so each thread includes: proposed/not-implemented status, current SDK surface, missing host seam, Plan Mode parity use, reusable non-Plan plugin examples, decisions needed, and fixture acceptance criteria.

RFC Contents

The full RFC packet covers:

  • current SDK research against existing hooks, using #71427 as the comparison bar
  • reusable SDK capability matrix across public SDK, trusted/bundled SDK, gateway protocol, UI descriptors, runner boundary, lifecycle cleanup, and fixture tests
  • plugin archetype matrix for approval workflows, deploy/release, budget guards, memory/context, review/CI, incidents/tickets, channel integrations, workspace policy, telemetry/exporters, and long-running jobs
  • #71676 entry-point coverage map for Plan Mode parity
  • per-hook TypeScript-shaped API sketches
  • expected host files for each implementation slice
  • authorization, trust-tier, disablement, cleanup, and failure semantics
  • fixture-plugin acceptance tests for the future hook implementation PR
  • Plan Mode migration sequence and parity checklist

Change Type

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Related #71676
  • Related #71732
  • Related #71733
  • Related #71734
  • Related #71735
  • Related #71736
  • Related #71737
  • This PR fixes a bug or regression

Verification

Verified locally:

  • pnpm format:docs:check
  • pnpm lint:docs
  • pnpm docs:check-mdx
  • pnpm docs:check-links

Human Verification

  • Confirmed the docs nav no longer places the proposal under stable SDK reference.
  • Confirmed both docs pages warn that the named APIs are proposed, not implemented.
  • Confirmed the RFC packet includes a #71676 entry-point coverage map.
  • Confirmed all six live issue bodies are expanded beyond Plan Mode-only examples.
  • Did not run runtime Plan Mode behavior because this PR is docs/RFC-only and implements no hooks.

Compatibility / Migration

  • Backward compatible? Yes, docs-only.
  • Config/env changes? No.
  • Migration needed? No.

Risks and Mitigations

  • Risk: reviewers mistake the RFC for implemented SDK reference.
    • Mitigation: warning callouts plus Plugin design RFCs nav placement.
  • Risk: proposal appears Plan Mode-specific.
    • Mitigation: reusable SDK matrices, non-Plan plugin examples, and expanded issue bodies.
  • Risk: proposal overclaims parity.
    • Mitigation: #71676 entry-point coverage map and explicit note that actual parity requires the future hook implementation PR plus fixture tests.

Next Step After This PR

If maintainers accept the RFC direction, the next PR should implement the generic host hooks with a tiny fixture plugin. Only after that should Plan Mode itself move into a bundled plugin and be audited against #71676 for parity.

Changed files

  • docs/docs.json (modified, +4/-0)
  • docs/plan/plan-mode-plugin-host-hooks-rfc.md (added, +1289/-0)
  • docs/plugins/plan-mode-plugin-host-hooks.md (added, +492/-0)

Code Example

api.enqueueNextTurnInjection({
  sessionKey,
  id,
  role,
  content,
  reason,
  expiresAt,
  dedupeKey,
});

api.on("agent_turn_prepare", async (event, ctx) => ({
  prependSystemContext,
  prependUserMessages,
}));
RAW_BUFFERClick to expand / collapse

Summary

Add a host-owned durable queue for plugin next-turn injections plus a typed agent_turn_prepare hook so plugins can schedule future prompt additions with exactly-once semantics.

This is proposed SDK surface, not currently implemented API.

Why this matters

Plan Mode approval acceptance, revision, question answering, nudges, and subagent follow-ups must affect a future run exactly once. before_prompt_build can add current-turn context, but it is not durable enough and should not become a pending interaction queue.

The same primitive is useful for plugins that receive an approval, event, timer, channel callback, CI result, ticket update, or memory selection outside the current model call and need to feed the next turn safely.

Current SDK surface

OpenClaw currently has before_prompt_build, legacy before_agent_start, and in-memory system events that can prepend context to a prompt.

Those surfaces are useful but insufficient: they do not provide host-owned storage, exactly-once dequeue, retry-safe consumption, expiry, dedupe, disabled-plugin suppression, or a stable preparation boundary before retry/fallback/provider transforms.

Proposed solution

Expose APIs such as:

api.enqueueNextTurnInjection({
  sessionKey,
  id,
  role,
  content,
  reason,
  expiresAt,
  dedupeKey,
});

api.on("agent_turn_prepare", async (event, ctx) => ({
  prependSystemContext,
  prependUserMessages,
}));

The host owns storage, dequeue timing, prompt ordering, retry/fallback behavior, provider transform ordering, and consumption marking.

Reusable plugin examples

  • Plan Mode injects approved execution, revision requests, question answers, scheduled nudges, and subagent follow-ups.
  • Review plugins inject required fixes after asynchronous review.
  • Deployment plugins inject release checklists or post-approval deploy instructions.
  • Memory managers hydrate selected context exactly once before the next call.
  • Incident plugins inject escalation or handoff instructions after an SLA timer fires.
  • CI plugins inject the next diagnostic step after log fetching completes.
  • Channel plugins inject deferred replies or cross-channel follow-ups.
  • Budget plugins inject warnings, downgrade guidance, or ask-before-continuing prompts.

Decisions needed

  • Storage location for pending injections.
  • Dequeue timing relative to command handling, retries, fallback, and provider transforms.
  • Prompt ordering relative to before_prompt_build.
  • Expiry and dedupe behavior.
  • Disabled-plugin behavior for pending injections.
  • Diagnostic visibility for dropped, expired, or suppressed injections.

Acceptance criteria

  • A fixture plugin enqueues an injection and the next run receives it once.
  • Retry/fallback does not duplicate the injection.
  • Expired injection is discarded with a diagnostic event.
  • Plugin disablement suppresses or removes pending injections.
  • Existing before_prompt_build behavior remains compatible and ordered.
  • The fixture proves the queue survives the command-to-next-turn boundary.

References

extent analysis

TL;DR

Implement a host-owned durable queue for plugin next-turn injections with exactly-once semantics using the proposed api.enqueueNextTurnInjection and api.on("agent_turn_prepare") APIs.

Guidance

  • To achieve exactly-once semantics, ensure that the api.enqueueNextTurnInjection method is idempotent and that the dedupeKey parameter is used to prevent duplicate injections.
  • Verify that the api.on("agent_turn_prepare") hook is called before the next turn, allowing plugins to schedule future prompt additions safely.
  • Consider implementing a retry mechanism for failed injections to ensure that they are not lost in case of errors.
  • Evaluate the storage location for pending injections, such as a database or a message queue, to ensure durability and reliability.

Example

api.enqueueNextTurnInjection({
  sessionKey: 'example-session',
  id: 'example-injection',
  role: 'example-role',
  content: 'example-content',
  reason: 'example-reason',
  expiresAt: new Date().getTime() + 30000, // 30 seconds
  dedupeKey: 'example-dedupe-key',
});

Notes

The proposed solution requires careful consideration of the storage location, dequeue timing, prompt ordering, expiry, and dedupe behavior to ensure that the queue is reliable and efficient.

Recommendation

Apply the proposed workaround using the api.enqueueNextTurnInjection and api.on("agent_turn_prepare") APIs to achieve exactly-once semantics for plugin next-turn injections. This approach provides a durable and reliable solution for scheduling future prompt additions.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#installation#tensor shape#autograd error#model save/load

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [RFC] Durable next-turn injections and agent turn preparation hooks [1 pull requests, 1 comments, 1 participants]