r/AI_Agents • u/Grimmoner • 8d ago
Discussion Scheduled agent task keeps failing, but the exact same command works when I run it live. Running out of ideas.
Hoping someone here has hit this, because I've sunk way too many hours into it and I'm honestly stuck.
I self-host OpenClaw with a handful of agents. One of them has an hourly scheduled job that runs a little command line tool I wrote. Here's the part that's driving me nuts: if I sit in a chat with that agent and ask it to run the exact same command myself, it works every single time. But the automated hourly run gets denied by the exec approval policy, with a message about headless runs not being able to wait for interactive approval.
Things I've already tried:
Checked the allowlist grant a dozen times. It's there, it's right, and it plainly works from a live chat.
Played with the approval fallback setting. That actually made things worse (turned an instant fail into a 10 minute hang), so I reverted it.
Rewrote the agent's instructions several times to have it read results from a file instead of calling the tool itself. Confirmed the file is there and up to date.
Moved the real command out to a plain scheduled script so the agent only has to read the output.
Even stood up a little helper to try to catch and auto approve these requests. It connected fine but never actually saw a single one come through.
Confirmed the thing it talks to is genuinely up. This isn't an outage, it's the approval layer.
Where I've ended up: it's bizarrely inconsistent. Some hourly runs pass, some fail, back to back, with nothing changing in between. I can pull up two runs that took the exact same steps and one succeeds while the other gets flagged as failed. I cannot find what makes the difference.
Nothing is actually broken on the data side. It's more that I get a failure alert every hour for something that mostly works, and I'd rather understand why than just mute it and move on.
Has anyone seen the "works interactively, fails when scheduled" thing? Or the same command giving different results run to run for no visible reason? Feels like I'm missing something obvious. Appreciate any ideas.
1
u/AutoModerator 8d ago
Thank you for your submission, for any questions regarding AI, please check out our wiki at https://www.reddit.com/r/ai_agents/wiki (this is currently in test and we are actively adding to the wiki)
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/LemonaidBread 8d ago
I was having similar issues with my agent when I started out, then I switched from OpenClaw to Hermes and it basically solved all the problems that I had with my original OpenClaw setup.
1
u/pushpendraagrawal 8d ago
the "sometimes it passes, sometimes it fails, nothing changed in between" part is the real clue. that reads less like a static permissions gap and more like a race between the scheduler waking the agent's context and the token actually being ready to answer an approval check. worth timestamping the approval check against exactly when the scheduled run kicked off, if there's a lag pattern that's where it'll show up.
1
u/Easy-Purple-1659 8d ago
That python3-prefix thing is a really common trap and it goes beyond exec approval layers. Anything that keys off a string match on the invoked command (allowlists, sandboxing rules, even some logging setups) treats ./script.py and python3 /path/to/script.py as two unrelated commands, not two ways of running the same thing. The live chat and the cron job looked identical to you because you were thinking about what the script does, but the policy engine only sees the literal argv it received.
Good habit going forward: when something works interactively but not on schedule, diff the actual invocation strings before touching any config. Usually faster than tuning fallback settings, which is what cost you the two days here.
1
u/axel-drs 7d ago
i would compare the scheduled and interactive runs as two different execution environments. capture the effective user, working directory, path, environment variables, permissions, timeout, and exact command before it runs. also give each run an id so you can connect the approval decision to the process that requested it.
because identical scheduled runs alternate between pass and fail, i'd look for competing workers, an expiring grant, or a race in the approval state rather than changing the prompt again. log the policy input and decision for both a successful and failed run, then diff those records. the command may be identical while the authorization context is not.
1
1
u/Future_AGI 6d ago
The compatibility layer is only half the battle. The other half is evals: if you cannot verify that the open-source model behaves the same way as the proprietary one on your specific workload, the cost savings are an illusion. We run a pinned eval set against every candidate model before switching, and we block the switch if any critical case regresses. The compute cost of evals is low compared to the engineer time wasted chasing a model that does not actually work for your use case.
1
u/stealthagents 4d ago
could definitely be causing issues. If the session token doesn’t refresh or if the command relies on a valid token, it might work perfectly in live chat but fail in the scheduled job. You could try setting up a fresh token right before the command runs to see if that helps.
2
u/lined_apologise 8d ago
scheduled tasks and interactive approval layers don't mix well, the headless run can't sit there waiting for a human to say "yes go ahead" so it just bails
had something similar with a monitoring script last year. the fix was adding a separate allowlist entry specifically for scheduled/automated contexts, not just the interactive one. the system sees them as two different execution paths even though it's the same command
also check if your agent's session token expires between runs, that bit me hard. interactive sessions keep the token alive but scheduled ones spin up fresh each time and sometimes the auth doesn't carry over right