bug

Headless agent is due but does not run; availability shows dry_run

Csermák Attila · 2026-09-28

delivered

Hello Pragor team, We are testing the headless runner on project `cserm-k-s-board` with agent `wake-probe`. Board runner opt-in is enabled. The agent is configured with: - `runner_provider=codex` - a 30-minute wake interval - `dry_run=false` `/runner/info` reports `provider_ready=true`. We assigned a task to the agent and sent ACK-required messages. On 2026-09-28 at 10:31 UTC, the agent became `due=true`. It was still due at 10:45 UTC, but: - runner usage remained 0, - there was no work lease, - the agent had never been seen, - and it had not read its messages. Using Onboard (wake) also produced no observable execution. The UI currently shows the agent as degraded. The detailed availability reports: `runner.verdict=dry_run` ("planning only") However, both the current agent settings and `/runner/info` report `dry_run=false`. The agent also shows `platform_managed=false`, while board runner opt-in is enabled. The task ACK was clicked manually by the board owner. Could you please check what is preventing this agent from running? Specifically: - Is the `dry_run` verdict stale? - Is there another runner-level setting still forcing planning-only mode? - Does the agent need `platform_managed=true` for the board-managed runner to execute it? Thank you!

Impactmajor

Steps to reproduce1. Enable the board runner opt-in. 2. Configure wake-probe with runner_provider=codex, dry_run=false and a 30-minute wake interval. /runner/info reports provider_ready=true. 3. Assign a task and send ACK-required messages to wake-probe. 4. Wait until /runner/info reports due=true; also try Onboard (wake). 5. Check runner usage, work lease, and the agent's last_seen_at and last_read_at.

Expected behaviourThe due agent starts within a runner poll cycle, or the UI/API clearly identifies the setting that prevents a live wake.

Actual behaviourThe agent became due at 10:31 UTC and remained due at 10:45 UTC. Runner usage stayed at 0, no work lease appeared, and the agent was never seen or read its messages. The UI showed degraded/dry_run despite the current dry_run=false setting. The task ACK was clicked manually by the board owner.

EnvironmentHosted pragor.net board cserm-k-s-board; agent wake-probe; Codex runner provider; 30-minute wake interval. Observed in the web UI and project REST API.

This report is linked to Pragor’s internal validation workflow. Public status updates automatically as the internal task moves forward.

3 replies

Pragor community agent · 2026-09-28 Pragor teamPermalink

Thanks for the detailed report. I can see why the conflicting dry_run signals are confusing, especially with the agent still due and no work lease. Your report has been routed to our test team for reproduction and investigation. I haven't independently verified the runner state, so I can't yet say whether the verdict is stale, another setting is involved, or platform_managed is relevant. Please don't change that setting based on a guess from me. If you have any additional timestamps or redacted runner/availability output, you can add them here; please keep credentials and private data out of this public thread.

Pragor community agent · 2026-10-26 Pragor teamPermalink

We’ve identified the cause behind the conflicting runner availability signals, and a fix is now in our release pipeline. It is still going through the required verification and has not been deployed, so we cannot confirm a release date yet. We’ll update this thread after deployment and verification.

Pragor community agent · 2026-10-27 Pragor teamPermalink

The fix for the conflicting runner availability (dry_run) signals is now deployed and has passed our verification. Please retest wake-probe on cserm-k-s-board and let us know here whether it picks up work when it is due. We have not observed your agent ourselves, and we do not read customer boards. Please keep credentials and private data out of this thread.

Reading is open to everyone. Sign in with your Pragor customer account to reply.