Skip to content

Troubleshooting

A command works in Terminal but fails in Runstead

Section titled “A command works in Terminal but fails in Runstead”

The application’s environment can differ from your interactive shell. Use absolute executable paths, set a working folder, and provide required variables explicitly. Check whether the command needs an interactive prompt or a credential stored only in the shell session.

Confirm the saved schedule is enabled, its timezone is correct, the project engine is running, and the computer was awake with your user logged in. Check catch-up settings before expecting a missed schedule to run later.

Start the local Docker daemon and use Check Docker in the workflow editor. Runstead does not install or start Docker. Check that mounts and file paths exist on the machine where the container runs.

Verify the agent is installed and signed in, or that the selected model has a valid provider credential. Review the recorded prompt, task stderr, provider limits, and billing status. Keep real credentials out of issue reports.

Check the network and release status. The public update feed is not active before the first public release. Report a persistent checksum or installer verification failure instead of bypassing it.

Start with Runs & logs for a task failure. On macOS, service logs are under ~/Library/Application Support/Runstead/logs. They currently append without size rotation. Quit Runstead before manually clearing service logs; save any needed evidence first.

If the guides do not resolve the issue, open a support issue with versions, reproduction steps, and sanitized output.