note that a Windows host cannot hand its sign-in to the container

README.md

@@ -101,6 +101,16 @@ msedge --user-data-dir="<repo>\data-dir" --profile-directory=Default https://rew
 
 Close every window of that profile afterwards. Chromium allows one process per profile directory, so a window left open on the host stops the container from starting.
 
+**This does not work from a Windows host.** Chromium encrypts cookie values with a key held by the operating system, and on Windows that key is wrapped with DPAPI and tied to the Windows account that wrote it. The Linux container has no DPAPI, so it cannot unwrap the key and every cookie in the profile is unreadable to it. The volume carries the file in and the browser then ignores its contents: a profile signed in on the host reported 73 cookies on disk, of which Edge in the container could read 19 — the ones it had just set itself — while `.MSA.Auth` and `ANON`, the cookies the sign-in actually rests on, came back absent. The container starts, looks healthy and behaves as though it were logged out.
+
+Sign-in has to happen wherever the container will read it, so on a Windows host run the bot directly instead:
+
+```sh
+python src/main.py
+```
+
+Only the Windows case is measured here. A Linux host is expected to work, since the container falls back to the same scheme when no keyring is present, and macOS is expected to fail the same way for the same reason as Windows — it wraps the key with the login Keychain, which the container also cannot reach. Neither was tested.
+
 **Provide the visual search image on the host too.** `visual_search.jpg` is not in the repository and is not built into the image, so create it once in the project root and the compose file mounts it in:
 
 ```sh