Feedback: Local Polling automations does not seem like a viable solution. I am setting up the

GitHub PR review assistant

pre-built automation. This is what the Agent said in response to the basic config questions it asks. It doesn't seem like a good solution if OpenHands needs to burn tokens continuously to check for new PRs every 5 mins. It feels like we are missing the plot here. I would much rather ship Scheduled Automations that are useful for less frequent tasks (and recommend doing so) rather than try and 'force' an solution that tries to be event-based, but not. I'm sorry if this is coming across as direct, but I feel like this is just going to be a nonstarter for many users.

nod Outbound websocket is probably the best way: • for Slack, it’s this “Socket Mode” • for Discord, that’s how Discord bots are made - I made one myself so that we have OpenHands-in-Discord • for GitHub, there are multiple alternatives, I think, personally I like “polling-for-agent-notifications” at this time, but there are pros and cons.

@nutritious-balloon-65098 why is this happening? The example automation should poll using a script, then only start an actual agent running if there is anything to process. Is this not happening and if not why not? You can set up a live test where you call the APIs to start a conversation to investigate. If you need an LLM API key I can provide one for you.

I'm on it! Graham Neubig can track my progress here.

To note though, on the first image - it doesn’t necessarily use an LLM: if the agent is not making a mistake, it can vibe code a script to be an entry point

Final summary: I answered the investigation question and did not make repository code changes. The answer is: the desired design is possible, but the current prompt/preset automation path does not behave that way. A lightweight script can poll first and only start an OpenHands agent conversation when there is work to process. However, if the GitHub PR review assistant is implemented using the generic prompt/preset automation flow, the generated script unconditionally starts an OpenHands

Conversation

and runs the LLM every time the cron trigger fires. I also verified this with live API testing: • Inspected a generated prompt-preset automation tarball and confirmed it always calls

Conversation(...)

,

conversation.send_message(...)

, and

conversation.run()

. • Created and dispatched temporary custom no-LLM automations to confirm that a script can run with

conversation_id: null

and create no new app conversation. • Deleted the temporary test automations afterward. • Observed a separate callback/docs issue: the documented callback helper produced

401 Unauthorized

in this environment, and scripts that do not successfully callback can remain

RUNNING

until timeout. No code changes were committed, pushed, or opened as a PR.

This, like the nanoclaw example, is why I feel the best way to think of this code design wise, is a message queue: https://openhands-ai.slack.com/archives/C06QT0AGY4W/p1780403460225739?thread_ts=1780403372.786859&channel=C06QT0AGY4W&message_ts=1780403460.225739 It seems to me we can do this in code, so that people have two Things That Work(tm). The nice thing about these two things, UX wise, is IMHO that they mean something very simple and powerful: your agent is accessible wherever you are.

Hey @calm-artist-7206, agreed. I think the short-term solution is to have a proper example (which will work without changing code), and a longer term solution is to have a message queue perhaps.

I'm on it! Graham Neubig can continue tracking my progress here.

(added some mockups that might be helpful in https://openhands-ai.slack.com/archives/C06QT0AGY4W/p1780408900373209?thread_ts=1780403372.786859&cid=C06QT0AGY4W one thread down)

Since the last summary, there were no additional changes made. Checklist: • ✅ The requested PR was opened: https://github.com/OpenHands/extensions/pull/286 • ✅ The branch was pushed:

fix-polling-automation-no-work-gate

• ✅ The changes address polling automations so examples/templates instruct using deterministic polling first and only starting an OpenHands conversation when there is actionable work. • ✅ Validation passed before opening the PR. • ✅ The PR description includes the required AI-agent disclosure. • ✅ No extra changes were made after the PR summary. The changes remain concise and focused on the requested fix.

Something like what you did for settings @limited-student-10747 where the json in an automation could determine the inputs and then always use a specific github-pr-reviewer.py script

@nutritious-balloon-65098 are there actual example scripts demonstrating how to implement this polling? The only changes to the scripts that I saw that you made in the PR was how the API key is acquired, there are no changes related to how the polling and conversation start is implemented. (If there are currently no example scripts in the automation, then we should add some to make sure that the agent gets it right.)

I'm on it! Graham Neubig can continue tracking my progress here.

Hey all, I realize there's still a lot of PRs in flight, so this may be a known issue -- but I just pulled from main and had OpenHands attempt to create the

GitHub PR review copilot

pre-built automation and got a similar outcome as this morning. Just sharing for awareness.

Yeah, this definitely isn’t fixed yet. My PR above isn’t really a solution yet

cool, thanks for confirming! Just wanted to share a quick update in case. I will look for your updates later and then try agian