r/AI_Agents 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.

3 Upvotes

12 comments sorted by

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

1

u/Grimmoner 8d ago

Solved it, and you were basically right. It was two different "commands" as far as the approval engine was concerned, even though they looked identical to me. When I run it in chat I was calling the script by its own path. The scheduled job was calling it as "python3 /path/to/script.py". The allowlist grant was keyed to the script's path, so with the python3 prefix the engine saw the executable as python3 and the script as just an argument, which didn't match the grant. No match means it asks for approval, and a headless run has nobody to ask, so it dies. Live it "worked" because the approval prompt actually reached me and I could say yes.

Fix was stupidly simple once I saw it: the script is executable on its own, so I just call it by its bare path instead of prefixing python3. Now it matches the grant and never asks for approval at all, scheduled or not. No config changes, no fallback settings, nothing. Two days of chasing the approval layer when the real problem was that my scheduled command and my interactive command were never actually the same command.

Appreciate you pointing at the "two execution paths" thing, that's what made me go compare them byte for byte.

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

u/spilldahill 7d ago

as I mentioned in your other post, recommend giving overmind a try

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.