Unable to find bucket matching 'aw-watcher-window_unknown' (hostname filter set to 'None')

[Ramadas108]

• I am on the latest ActivityWatch version.
• I have searched the issues of this repo and believe that this is not a duplicate.

• Windows 11:
• Version: v0.13.2:

Describe the bug

To Reproduce

Expected behavior

Documentation

Additional context

[github-actions]

Hi there!
As you're new to this repo, please make sure you've used an appropriate issue template and searched for duplicates (it helps us focus on actual development!). We'd also like to suggest that you read our contribution guidelines and our code of conduct.
Thanks a bunch for opening your first issue! 🙏

[TimeToBuildBob]

The bucket name aw-watcher-window_unknown indicates that socket.gethostname() returned "unknown" when aw-watcher-window started. This typically happens in certain container, VM, or misconfigured network environments on Windows where the hostname isn't set.

The find_bucket() query function (in aw-core) uses a substring match on the bucket name and an exact match on the hostname metadata. When the hostname stored in the bucket metadata ("unknown") doesn't match the hostname the webui expects (the actual machine hostname), the query fails with this error.

Workaround: Check your Windows hostname:

hostname

If it returns something other than unknown, the mismatch is the issue. You can fix it by:

1. Setting your Windows hostname properly (Settings → System → About → Rename this PC)
2. Restarting ActivityWatch so it creates a bucket with the correct hostname

Could you share:

• What hostname returns in PowerShell
• Whether you're running in a VM, container, or have recently changed your computer name
• The output of http://localhost:5600/api/0/buckets in your browser (shows all bucket names and hostnames)

This would help confirm the root cause.

[TimeToBuildBob]

This looks like it's related to how find_bucket() handles partial bucket IDs. The query builder was improved in aw-webui PR ActivityWatch/aw-webui#760 (merged Feb 2026) which reduces unnecessary find_bucket() calls.

However, the core issue here is that your system's hostname resolved to unknown, which creates buckets named aw-watcher-window_unknown. This is typically a Windows hostname configuration issue.

Workaround: Check your hostname in PowerShell (hostname) and rename the computer if needed (Settings → System → About → Rename this PC), then restart ActivityWatch.

The fix in #760 should help with bucket matching in the next release (post v0.13.2).

[TimeToBuildBob]

Quick correction on my earlier diagnosis: I was too confident in saying this was definitely a Windows hostname misconfiguration.

What I can support more confidently from the code/state now is:

• aw-watcher-window_unknown means ActivityWatch ended up with a bucket whose hostname is literally unknown
• the error is happening in query resolution (find_bucket(...)), not necessarily because Windows itself is misconfigured
• the webui-side bucket-query fix I referenced earlier (ActivityWatch/aw-webui#760) is not in the latest bundled activitywatch release (v0.13.2), since that release predates the PR by a long time

So the current best-supported status is:

1. there is definitely an unknown-hostname bucket involved
2. v0.13.2 does not include the newer aw-webui query behavior
3. we still need more concrete data before claiming the OS hostname is the root cause

If you want, the most useful next debugging data would be:

• output of hostname in PowerShell
• the full JSON from http://localhost:5600/api/0/buckets
• whether the problem happens only in Category Builder / query-like views, or also elsewhere in the UI

That would let us separate:

• bucket metadata problem (unknown getting written unexpectedly)
  from
• webui/query selection problem (released UI handling this case poorly).

So: my previous comment should be read as a hypothesis, not a confirmed root cause.

[oriNesher]

hi there,
I have the same bug

here is my JSON from http://localhost:5600/api/0/buckets -

and as text if u want to copy paste any of it for some reason:

{"aw-watcher-afk_leptop_ori": {"id": "aw-watcher-afk_leptop_ori", "created": "2025-12-15T19:15:58.016347+00:00", "name": null, "type": "afkstatus", "client": "aw-watcher-afk", "hostname": "leptop_ori", "data": {}, "last_updated": "2026-03-16T20:15:14.211000+00:00"}, "aw-watcher-window_leptop_ori": {"id": "aw-watcher-window_leptop_ori", "created": "2025-12-15T19:15:58.330368+00:00", "name": null, "type": "currentwindow", "client": "aw-watcher-window", "hostname": "leptop_ori", "data": {}, "last_updated": "2026-03-16T20:15:16.427000+00:00"}, "aw-stopwatch": {"id": "aw-stopwatch", "created": "2025-12-15T19:20:40.104890+00:00", "name": null, "type": "general.stopwatch", "client": "aw-webui", "hostname": "unknown", "data": {}}, "aw-watcher-web-firefox_leptop_ori": {"id": "aw-watcher-web-firefox_leptop_ori", "created": "2025-12-15T19:22:08.811917+00:00", "name": null, "type": "web.tab.current", "client": "aw-client-web", "hostname": "leptop_ori", "data": {}, "last_updated": "2026-03-16T20:15:16.530000+00:00"}}

when I write hostname in PowerShell it says laptop_ori

love your app, thank you <3

[TimeToBuildBob]

Tracked this down further and the real bug is in the shared QueryOptions component in aw-webui, not just in query resolution.

Root cause:

• bucketsStore.hosts can put unknown first when a special bucket like aw-stopwatch was updated more recently than the real window/AFK buckets
• QueryOptions then defaulted to hostnameChoices[0]
• Category Builder only avoids unknown when hostname is still blank, so once QueryOptions had already set it to unknown, it synthesized aw-watcher-window_unknown

Upstream fix PR:

• fix(query-options): prefer known hosts over unknown defaults aw-webui#809

That PR makes QueryOptions prefer known hosts over unknown by default, while still keeping unknown available as a fallback when it is the only host.

After that lands, aw-server-rust / the bundled app will still need the usual aw-webui bump before the fix reaches a release.