AI-assisted PR. Implemented and verified with Claude (Claude Code). I have reviewed and understand the change and own the final diff.

Summary

Replace the hardcoded 60-second COMPACTION_RETRY_AGGREGATE_TIMEOUT_MS with
resolveCompactionTimeoutMs(params.config), which reads the user-configured
agents.defaults.compaction.timeoutSeconds (default 180s).

On large sessions (~200K tokens), the compaction summary model call can take
143–187s. The hardcoded 60s deadline abandons valid results before the
provider finishes, triggering a self-compounding retry storm where every
attempt times out while the provider is still processing. The result is
paid for by the user but discarded by OpenClaw.

Fixes #94391

Real behavior proof

Behavior addressed:
Compaction retry aggregate timeout now respects the user-configured
agents.defaults.compaction.timeoutSeconds instead of a hardcoded 60s.
Large sessions whose compaction model calls exceed 60s no longer suffer
a self-compounding retry storm.

Real environment tested:
Linux x64, Node 24.13.1

Exact steps or command run after this patch:

node scripts/run-vitest.mjs src/agents/embedded-agent-runner/run/compaction-retry-aggregate-timeout.test.ts

After-fix evidence:

✓ 8 passed — all compaction retry aggregate timeout tests pass

Observed result after the fix:
resolveCompactionTimeoutMs(params.config) now returns the user-configured
value (or the default 180s), ensuring the aggregate retry deadline matches
the compaction model timeout. The previous 60s hardcoded floor is removed.

What was not tested:

• Live end-to-end with 200K-token session compaction
• Provider call duration >180s scenarios

Changes

One line changed in src/agents/embedded-agent-runner/run/attempt.ts:

- const COMPACTION_RETRY_AGGREGATE_TIMEOUT_MS = 60_000;
+ const COMPACTION_RETRY_AGGREGATE_TIMEOUT_MS =
+   resolveCompactionTimeoutMs(params.config);

resolveCompactionTimeoutMs reads from the existing config path
agents.defaults.compaction.timeoutSeconds and was already imported
in this file (line 257).

Risk / scope

• User-visible behavior change: Yes — compaction retry waits longer
  when the user configures a higher timeout
• Config/API change: No
• Breaking: No — only raises a previously-too-low floor
• Highest risk: users who relied on the 60s cap for fast-fail may
  see longer waits. Mitigation: they can set compaction.timeoutSeconds
  to a lower value