Summary
internal/driver/openclaw/jobs.go hardcodes payload.timeoutSeconds to 300 for every generated OpenClaw native cron job.
That ignores any service-level OpenClaw timeout configured via existing CONFIGURE directives such as:
CONFIGURE openclaw config set agents.defaults.timeoutSeconds 900
Current Code
internal/driver/openclaw/config.go already applies rc.Configures into the rendered OpenClaw config, so agents.defaults.timeoutSeconds can be set declaratively today.
internal/driver/openclaw/jobs.go does not reuse that resolved value when rendering config/cron/jobs.json.
- The hardcoded path is here:
Payload: jobPayload{Kind: "agentTurn", Message: inv.Message, TimeoutSeconds: 300}
Why This Is A Bug
Clawdapus currently allows the OpenClaw runtime config and the generated native cron payloads to diverge.
If a service sets a larger default agent timeout in openclaw.json, the native cron jobs rendered by Clawdapus still carry a 5 minute ceiling. That means timeout behavior depends on which generated surface executes the work rather than on one resolved source of truth.
Reproduction
- Configure an OpenClaw service with:
CONFIGURE openclaw config set agents.defaults.timeoutSeconds 900
- Include one or more scheduled invocations that cause Clawdapus to render
config/cron/jobs.json.
- Run
claw up.
- Inspect the generated OpenClaw config and cron store.
Observed
openclaw.json contains agents.defaults.timeoutSeconds = 900.
config/cron/jobs.json still contains payload.timeoutSeconds = 300.
Expected
Generated OpenClaw cron payloads should derive their timeout from the same resolved source as the OpenClaw config.
At minimum:
- if
agents.defaults.timeoutSeconds is configured via CONFIGURE, use that value in jobs.json
- reject invalid non-positive timeout values during generation
- add regression tests for default behavior and configured overrides
Scope
This issue is specifically about the OpenClaw-native cron payload rendered by Clawdapus on the current branch, not an external scheduler wake command.
Summary
internal/driver/openclaw/jobs.gohardcodespayload.timeoutSecondsto300for every generated OpenClaw native cron job.That ignores any service-level OpenClaw timeout configured via existing
CONFIGUREdirectives such as:Current Code
internal/driver/openclaw/config.goalready appliesrc.Configuresinto the rendered OpenClaw config, soagents.defaults.timeoutSecondscan be set declaratively today.internal/driver/openclaw/jobs.godoes not reuse that resolved value when renderingconfig/cron/jobs.json.Why This Is A Bug
Clawdapus currently allows the OpenClaw runtime config and the generated native cron payloads to diverge.
If a service sets a larger default agent timeout in
openclaw.json, the native cron jobs rendered by Clawdapus still carry a 5 minute ceiling. That means timeout behavior depends on which generated surface executes the work rather than on one resolved source of truth.Reproduction
config/cron/jobs.json.claw up.Observed
openclaw.jsoncontainsagents.defaults.timeoutSeconds = 900.config/cron/jobs.jsonstill containspayload.timeoutSeconds = 300.Expected
Generated OpenClaw cron payloads should derive their timeout from the same resolved source as the OpenClaw config.
At minimum:
agents.defaults.timeoutSecondsis configured viaCONFIGURE, use that value injobs.jsonScope
This issue is specifically about the OpenClaw-native cron payload rendered by Clawdapus on the current branch, not an external scheduler wake command.