I am seeing intermittent generation failures on v1.3.7 with an otherwise connected browser session:
403 PERMISSION_DENIED
The caller does not have permission
The error is returned by Google during :streamGenerateContent, after the local API-key check and browser request handoff. Restarting/reloading the browser context does not make it reliably recover.
One detail that seems worth making configurable: src/core/BrowserManager.js currently launches every installation with the same hard-coded Build App URL:
this.targetUrl = "https://ai.studio/apps/cab9ab6c-44f9-4e7a-8972-037f8ae177ab";
That means every deployment depends on the same shared Build App. It also makes it difficult to tell whether a 403 is caused by the account/session/egress or by the shared app itself.
This seems related to the final finding in #232: the original OAuth explanation was a false positive, while creating/forking a new Build App and changing targetUrl to that app ID made the same 403 go away.
#232 (comment)
Could the Build App URL be exposed as a small, backward-compatible setting, for example:
AI_STUDIO_BUILD_APP_URL=https://ai.studio/apps/<app-id>
with the current URL kept as the default? Documenting it in .env.example / Docker examples would be enough for now. Per-account URLs could be considered later; a global override already avoids source patches and makes this class of 403 much easier to isolate.
I am seeing intermittent generation failures on v1.3.7 with an otherwise connected browser session:
The error is returned by Google during
:streamGenerateContent, after the local API-key check and browser request handoff. Restarting/reloading the browser context does not make it reliably recover.One detail that seems worth making configurable:
src/core/BrowserManager.jscurrently launches every installation with the same hard-coded Build App URL:That means every deployment depends on the same shared Build App. It also makes it difficult to tell whether a 403 is caused by the account/session/egress or by the shared app itself.
This seems related to the final finding in #232: the original OAuth explanation was a false positive, while creating/forking a new Build App and changing
targetUrlto that app ID made the same 403 go away.#232 (comment)
Could the Build App URL be exposed as a small, backward-compatible setting, for example:
with the current URL kept as the default? Documenting it in
.env.example/ Docker examples would be enough for now. Per-account URLs could be considered later; a global override already avoids source patches and makes this class of 403 much easier to isolate.