Again, thanks for the reply and apologies for my tardy follow-up.
"Prodigy/Python version?": v3.10 and v1.11.7
"Could you confirm that this issue persists across browsers?" Yes. I tested with latest Chrome, Firefox and Safari.
"Is there anything noteworthy when you look at the verbose Prodigy logs?" Unfortunately, there is no noteworthy information from the server. The browsers are rejecting the cookie because the cookies' domain (0.0.0.0) does not match localhost.
have VSCode ssh into the same machine and forward everything properly on my laptop
This is making me wonder if this is perhaps a firewall setting on your end. So just to check, are you able to run webservers just fine? Can you visit the fileserver via the browser when you run this in a folder with files:
I can browse also. If you check your browser's console log, you will see that the _prodigy_ cookie is rejected as the cookie's domain, 0.0.0.0, does not match the URL's host (e.g., localhost).
a) The cookie is not required and all is well, or
b) Due to the cookie being required, we are not able to deploy prodigy behind a proxy (e.g., some.internal.domain) and have prodigy listen a containerized interface (e.g., 0.0.0.0).
No browser extensions are loaded. The error is logged in both desktop Firefox and Safari consoles. Your screenshot looks like you are using Chrome. I did not test Chrome.
Other than the console warning, I am not sure what the cookie's purpose is. Prodigy is not always reliable (e.g., duplicate annotations in output). I thought the cookie issue might reduce reliability as it was the only logged error I could find in either server or browser session.
If it helps, my local prodigy setup is a docker image running prodigy that I attempt to access locally using port forwarding.
I'm unable to reproduce the warnings that you're seeing. So as long as the cookie warnings can be ignored, I would do that because they seem like they might be related to something that I cannot produce locally.
If it is a breaking issue, we could dive in further, but we'd need to think about how we might be able to get the error reproduced. Have you checked if this error persists on your colleague's machines or when you are on another network?