Summary
summary_timeout_seconds is accepted by settings, but entire checkpoint explain --generate still uses the hardcoded 30s timeout.
This makes the setting look configurable even though it has no effect for the current summary generation path.
Environment
- Entire CLI:
0.6.1 (774ee21f)
- OS/Arch:
darwin/arm64
- Go:
go1.26.2
I also checked current main / nightly v0.6.2-nightly.202605130712.1622abc5, and the generate path still appears to use the hardcoded checkpointSummaryTimeout.
Reproduction
With a large checkpoint transcript:
entire checkpoint explain --checkpoint ebd73f222193 --generate
Output:
Using Claude Code for summary generation.
Generating checkpoint summary...
✗ Summary generation timed out after 30s
Then configure a longer timeout:
{
"enabled": true,
"summary_timeout_seconds": 3600
}Run the same command again:
entire checkpoint explain --checkpoint ebd73f222193 --generate
It still times out after 30s.
Expected Behavior
summary_timeout_seconds should either:
- be honored by
checkpoint explain --generate, or
- be removed/hidden until it is supported.
Ideally:
- unset or non-positive: keep current default behavior
- positive value: use that value as the summary generation deadline
Actual Behavior
The setting round-trips through config, but explain --generate still uses the package-level default:
const defaultCheckpointSummaryTimeout = 30 * time.Second
var checkpointSummaryTimeout = defaultCheckpointSummaryTimeout
The settings field exists:
SummaryTimeoutSeconds int `json:"summary_timeout_seconds,omitempty"`
and has a helper:
func (s *EntireSettings) SummaryTimeoutValue() time.Duration
but that helper does not appear to be consumed by the generate path.
Related Context
There is an open PR that appears related:
That PR seems to move toward stream-driven progress and a different deadline model, but it is still open. In the meantime, the released CLI exposes a setting that appears configurable but does not affect the behavior.
Why This Matters
Large real-world checkpoints can exceed 30 seconds to summarize, especially when the transcript is long. In that case the only workaround is to avoid --generate or patch/build the CLI locally.
A small fix could wire SummaryTimeoutValue() into the summary deadline selection while preserving the current 30s default.
Happy to open a narrow PR if maintainers prefer that over waiting for #964.
Summary
summary_timeout_secondsis accepted by settings, butentire checkpoint explain --generatestill uses the hardcoded 30s timeout.This makes the setting look configurable even though it has no effect for the current summary generation path.
Environment
0.6.1 (774ee21f)darwin/arm64go1.26.2I also checked current
main/ nightlyv0.6.2-nightly.202605130712.1622abc5, and the generate path still appears to use the hardcodedcheckpointSummaryTimeout.Reproduction
With a large checkpoint transcript:
Output:
Then configure a longer timeout:
{ "enabled": true, "summary_timeout_seconds": 3600 }Run the same command again:
It still times out after 30s.
Expected Behavior
summary_timeout_secondsshould either:checkpoint explain --generate, orIdeally:
Actual Behavior
The setting round-trips through config, but
explain --generatestill uses the package-level default:The settings field exists:
and has a helper:
but that helper does not appear to be consumed by the generate path.
Related Context
There is an open PR that appears related:
That PR seems to move toward stream-driven progress and a different deadline model, but it is still open. In the meantime, the released CLI exposes a setting that appears configurable but does not affect the behavior.
Why This Matters
Large real-world checkpoints can exceed 30 seconds to summarize, especially when the transcript is long. In that case the only workaround is to avoid
--generateor patch/build the CLI locally.A small fix could wire
SummaryTimeoutValue()into the summary deadline selection while preserving the current 30s default.Happy to open a narrow PR if maintainers prefer that over waiting for #964.