From c212ba8131d1daeede0f992e188e7989cb8a9c83 Mon Sep 17 00:00:00 2001 From: Ethan Stoner Date: Fri, 28 Aug 2026 13:57:11 -0700 Subject: [PATCH] note that a Windows host cannot hand its sign-in to the container --- README.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/README.md b/README.md index bb8b340..179e282 100644 --- a/README.md +++ b/README.md @@ -101,6 +101,16 @@ msedge --user-data-dir="\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