weird that curl works from the same container but the binding throws that jetty WWW-Authenticate thing. in my experience that usually means something in the http client path (proxy, middleware, or a 401 shaped weird) is confusing jetty even when a raw curl is fine.
id check if openHAB has an http proxy set under network settings, and whether the OpenAI TTS add-on is somehow going through a different route than your curl. also try regenerating the api key once just to rule out a stale secret in the binding config vs env.
if curl keeps working, its probably not openai itself. probably the add-ons http client. might be worth a github issue on the openai tts add-on with that exact exception.
There is no HTTP/HTTPS proxy configured in the container or in openHAB, and I also tested with the API key entered directly in the TTS service instead of using the environment variable.
The same curl request from inside the openHAB container still returns HTTP 200 and valid audio.
Also, OpenAI TTS worked for me with openHAB 5.1.1 and started failing with 5.2.x.
So this really looks like a regression in the HTTP client path rather than an OpenAI or network issue.
ahh so it worked on 5.1.1 and died on 5.2.x, that lines up with the binding/http client more than openai
jetty gets weird when something returns a 401-shaped response without WWW-Authenticate. curl just shrugs and keeps going, so same container / same key can still look fine from the shell
id probably file it on the openai tts add-on github with: ok on 5.1.1, broken 5.2.0+5.2.1, curl from the container is 200, no proxy, key hardcoded. that exception string is the useful part
temp workaround if you need voice now: a rule that shells out to curl against /v1/audio/speech and plays the file. ugly but it unblocks you while the binding catches up
