Automation stack fails without tzdata; Windows public skills clone breaks on : filenames

[jamiechicago312]

Summary

The local agent-canvas automation stack appears to have two environment-level failures that can block Slack channel monitor automations (and likely other automation-driven workflows):

1. Primary: the automation scheduler crashes when timezone data is unavailable
2. Secondary: public skill loading can fail on Windows because some skill command filenames contain :

Evidence

1) Automation scheduler crashes without timezone data

Observed log signatures:

• ModuleNotFoundError: No module named tzdata``
• ZoneInfoNotFoundError: No time zone found with key UTC``

This happens inside the automation scheduler poll loop, which means scheduled automations do not run reliably in environments without a system timezone database (notably Windows, and potentially slim container/runtime variants).

In this repo, openhands-automation==1.0.0a6 is provisioned from scripts/dev-with-automation.mjs (via uvx) and from docker/Dockerfile (via pip / uv pip), but the package itself does not declare tzdata as a dependency.

2) Public skill loading fails on Windows for colon-containing filenames

Observed log signature:

• error: invalid path skills/slack-channel-monitor/commands/slack-monitor:poll.md``

The public skills repo/package currently includes command files with : in their names (for example skills/slack-channel-monitor/commands/slack-monitor:poll.md). That is valid on POSIX filesystems but invalid on standard Windows Git checkouts, so any backend path that clones or updates OpenHands/extensions can fail there.

This is especially relevant because backend automation/preset paths still load public skills through the agent-server/SDK path, not only through the frontend-bundled @openhands/extensions catalog.

Impact

• Cron-triggered automations may never execute correctly in affected environments.
• Slack channel monitor setup / execution can fail on Windows because backend public-skill loading cannot materialize the extensions repo cleanly.

Likely fixes

Repo-local fix in agent-canvas

• Ensure tzdata is installed anywhere openhands-automation is provisioned:
  • dev stack (scripts/dev-with-automation.mjs)
  • combined Docker image (docker/Dockerfile)

Follow-up / upstream coordination needed

• Eliminate Windows-invalid : filenames from public skill command paths in OpenHands/extensions, or otherwise stop backend skill-loading paths from depending on a Git checkout that reproduces those paths on Windows.

Notes

I also checked the local automation DB in the failing environment and found no current automation/run rows, so I could not tie the failure to a single saved automation instance. The two runtime failures above appear sufficient to explain the behavior.

---

This issue was created by an AI agent (OpenHands) on behalf of the user.