### What variant of Codex are you using? CLI ### What feature would you like to see? Support a first-class hook output action that can request real Codex compaction before continuing the turn. Today a `Stop` hook can keep Codex going by returning: ```json { "decision": "block", "reason": "Run one more pass over the failing tests." } ``` That is useful, but it only sends `reason` back as a model-visible continuation prompt. If the hook returns `/compact` as the reason, Codex treats it a

Allow hooks to request real compaction before continuing

Open 💬 3 comments Opened May 17, 2026 by ducan-ne

What variant of Codex are you using?

CLI

What feature would you like to see?

Support a first-class hook output action that can request real Codex compaction before continuing the turn.

Today a Stop hook can keep Codex going by returning:

{
  "decision": "block",
  "reason": "Run one more pass over the failing tests."
}

That is useful, but it only sends reason back as a model-visible continuation prompt. If the hook returns /compact as the reason, Codex treats it as prompt text; it does not invoke the real /compact control path.

The requested feature is a supported hook output contract for triggering actual history compaction from a hook, especially from Stop, before optionally continuing with a hook-provided prompt.

For example, something along these lines:

{
  "hookSpecificOutput": {
    "hookEventName": "Stop",
    "action": "compact",
    "continuationPrompt": "After compaction, continue with one more validation pass."
  }
}

or another schema chosen by maintainers that makes the same behavior explicit.

Desired semantics:

The hook requests the same real compaction path as manual /compact / Op::Compact, not a model prompt containing /compact.
Codex compacts at most once per turn to avoid hook loops.
If a continuation prompt is supplied, Codex resumes after compaction using that prompt.
The behavior should be clearly separate from existing Stop continuation via decision: "block".
It should interact predictably with existing PreCompact and PostCompact lifecycle hooks when those hooks are available.

Additional information

I checked the current behavior in source and docs. The gap appears to be that compaction is a control operation, while Stop hook continuation is implemented as a synthetic user prompt:

Stop hook decision: "block" stores the reason as continuation prompt text.
The continuation prompt is recorded as a user message, so slash-command text like /compact is not routed through the TUI slash-command dispatcher.
The real compaction path is separate: /compact dispatches to Op::Compact, which starts a CompactTask.
Current PreCompact / PostCompact hook outputs are lifecycle-only and do not provide an action to request compaction.

Related issues, but not exactly this request:

#11912 asks for custom compaction hooks / compaction lifecycle support.
#17148 asks for PreCompact and PostCompact lifecycle hooks.
#21753 tracks broader Claude Code hook parity.

This issue is specifically asking for a hook output action that can trigger real Codex compaction, rather than relying on a hook to send /compact or a summarization prompt back to the model.

View original on GitHub ↗

3 Comments

Keesan12 · 3 months ago

A real compaction action from hooks makes sense, but it needs a small admission contract so hooks do not create their own continuation loop. I would expose at least compaction_requested, compaction_executed, continuation_prompt_used, and a once-per-turn guarantee in the resulting receipt. Otherwise operators will have a hard time telling whether the hook actually compacted or just injected another model-visible nudge. We have been treating that as a control-plane receipt problem in MartinLoop too.

Necmttn · 2 months ago

A hook-triggered compact action would be much easier to operate if Codex emitted a structured receipt for the turn.

Minimum receipt fields:

hook id and event name
compaction_requested
compaction_executed
reason skipped, if any
once-per-turn guard result
continuation prompt hash or source, if supplied
PreCompact / PostCompact hook ids that ran

That keeps the control action separate from model-visible prompt text. It also gives hooks and external tools a way to tell "the hook requested compaction and Codex did it" apart from "the hook merely asked the model to continue."

---

_Generated with ax._

GreyHat633 · 1 day ago

I’m running into this exact limitation in a real Codex Desktop workflow.

I use Codex hooks together with subagents to offload execution work from the main Sol thread. The delegation itself is working well, but the main thread keeps accumulating history, and repeated context replay has become the dominant cost.

In one measured long-running session:

508 Sol model cycles
60.65M total input tokens
59.80M cached input tokens
cached input alone accounted for roughly 74.5% of the Sol cost

Native same-thread compaction is extremely effective in the same workload. In another measured session, context dropped from 208,834 input tokens to 25,216 after native compaction, about an 87.9% reduction, while the same workflow continued.

Hooks are already sufficient for my tooling to identify a safe lifecycle boundary. The missing piece is exactly what this issue describes: a supported way for a hook to request the real native compaction path for the current Desktop thread.

I’ve deliberately avoided UI automation, modifying session history, proxying the Desktop app-server connection, or competing for the active thread, because those approaches are too fragile or risky for a rapidly updated Desktop application.

So a first-class hook action for native compaction — whether or not it uses the exact proposed action: "compact" schema — would unblock a real context-management use case for me.

I’d also be happy to test this on Windows Codex Desktop and provide before/after token and continuity data if an experimental implementation becomes available.