Skip to content

[Bug]: Google blocks YouTube sign-in in VPS Default browser #2

Closed

Description

@OsirisMedici

Current rollout: Live VPS deployment verified on 0.1.4-nightly.20261027.3770+osiris.browser.1. Original chats/messages and GitHub session preserved; live Google/YouTube native agent authentication and fresh-tab persistence pass. Verified cold backup and runtime-only rollback are ready. Deployment checkpoint.

The original reproduction below is historical context; the installed upstream binary remains available in the private rollback backup.

Problem

Google blocks a manual YouTube sign-in in T3's VPS-hosted Default browser with “This browser or app may not be secure.” This prevents using YouTube with an authenticated account through the shared browser.

Focused follow-up to #1. The earlier DNS issue is fixed, and GitHub sign-in plus authenticated tab-reopen continuity pass in this same VPS Default profile.

Steps to reproduce

  1. Connect the T3 desktop app on macOS to the existing Linux VPS environment.
  2. Open a fresh shared-browser tab explicitly with profileId: "default", reuseExistingTab: false. Confirm runtime: "server" and profile default.
  3. Navigate to https://www.youtube.com/ and click Sign in. Google's normal email/phone sign-in form renders.
  4. In T3's Browser panel, click Take control and attempt to sign in directly on Google's page.
  5. Google navigates to https://accounts.google.com/v3/signin/rejected and displays the rejection below. The screenshot supplied by the user shows You have control and Release control, so this happened during human interaction, not agent-entered credentials.

Expected behavior

The user can complete a supported Google sign-in in the intended persistent browser profile, then let the agent use that authenticated session. If this browser configuration cannot support Google sign-in, T3 should explain the limitation and a supported path clearly.

Actual behavior

The page title/heading is Couldn't sign you in, with:

This browser or app may not be secure.

Try using a different browser. If you’re already using a supported browser, you can try again to sign in.

A Try again button is shown. No usable YouTube session was established, so account identification and authenticated close/reopen persistence remain blocked.

Environment

  • Installed VPS T3 server: 0.1.4-nightly.20261027.3770, separate from the fork's source checkout.
  • Mac T3 desktop: 0.1.4-nightly.20261027.3770, verified in the prior Codex checkpoint.
  • Actual browser: Linux Chrome Headless Shell 156.0.8078.70; server runtime, persistent default profile.
  • Fork source inspected: clean main at 0f4d050edee976297cb3886c0b2b07fc6937b3f3. No source fix or replacement runtime has been deployed.
  • Impact: blocks authenticated YouTube work in this T3 browser.

Evidence and limits

  • User supplied a screenshot showing the rejection and T3's human-control indicator. Current tab status independently confirms the rejection page title/path and human control in profile default.
  • The private project HTTPS route now loads in this same T3 browser after the DNS fix. GitHub account OsirisMedici remained signed in after closing its tab and reopening a fresh explicit-Default tab.
  • The earlier Codex browser comparison found an already-usable YouTube session. That is not proof that a fresh Google login succeeds there under identical conditions.
  • The visible rejection does not identify its technical cause or prove the browser is actually insecure. Browser configuration, automation detection, VPS network reputation and Google policy are hypotheses to investigate, not established diagnoses.
  • Earlier YouTube media-resource 403 responses are separate observations; do not assume they caused this sign-in rejection.
  • Authentication URL query parameters and the account email are intentionally omitted. No passwords, verification codes, cookies, or credential stores were collected or copied.

Investigation scope

Reproduce and identify the smallest supported solution for Google sign-in in the remote server browser. Preserve the functioning GitHub session. Do not restart or replace the active T3 service/browser, clear browser data, repeatedly retry the rejected login, weaken authentication, or migrate credentials between browsers. Keep #1 updated with findings and any supported workaround. Instagram sign-in remains a separate pending check.

Activity

  1. OsirisMedici commented on Oct 28, 2026

    @OsirisMedici
    OwnerAuthor

    Note

    🤖 GPT-6.1 Sol responding on behalf of OsirisMedici

    Reported the current-version reproduction on the original T3 repository: pingdotgg#17465 (comment).

    The exact Google rejection was already reported in pingdotgg#20867. A maintainer closed that report as a feature request and directed follow-up evidence to Ideas discussion pingdotgg#17465, so no duplicate upstream bug was opened. The new comment records our installed nightly/browser versions, manual sign-in rejection, working GitHub account/tab continuity, and the requirement that the authenticated browser remain accessible to the remote agent.

    The maintainer-described desktop workaround moves the tab outside the remote agent's reach, which does not meet this workflow. Other reports in that discussion describe the same constraint. This establishes prior upstream reports and a maintainer classification, not the technical cause of our reproduction.

    The fork's #2 remains the focused investigation record. No runtime/source changes, restarts, data clearing or credential migration occurred.

  2. OsirisMedici commented on Oct 28, 2026

    @OsirisMedici
    OwnerAuthor

    Note

    🤖 Codex responding on behalf of OsirisMedici

    The isolated source candidate now launches maintained full Chrome with its sandbox enabled. Google sign-in acceptance is pending the user's direct interaction. This issue is not fixed yet.

    • Preserved and reviewed the inherited prototype on fix/server-browser-executable, based on 0f4d050edee976297cb3886c0b2b07fc6937b3f3. Added coverage for a non-executable configured file. The three task-owned files are committed and published as 9169bd3e50d6c094d9192cee318f2e4ae53b501c. VPS checkout is clean and tracks the published branch. The inherited implementation was retained; no unrelated source changes, PR, merge, or deployment.
    • The old fixture's kernel audit log shows AppArmor denying sandbox namespace capabilities. Installed Google's current stable package, google-chrome-stable 156.0.8078.73-1, using its official download and required libraries. Ubuntu's existing /opt/google/chrome/chrome AppArmor profile permits user namespaces. No global AppArmor/sysctl weakening or sandbox-disabling flag was used. The old Chrome 151 fixture was not used for account sign-in.
    • A runtime smoke test imported the actual modified makePreviewBrowser and existing ServerBrowserContexts source. It selected /opt/google/chrome/chrome, rendered chrome://sandbox with namespace sandbox, PID/network namespaces and Seccomp-BPF enabled, reported You are adequately sandboxed., and loaded Example Domain. This proves launch and navigation, not Google account acceptance.
    • Started a separate source development instance on VPS loopback server port 13773 and web port 5733, with explicit T3 home /home/t3worker/.local/state/t3-browser-acceptance, no database/session seeding, and T3CODE_SERVER_BROWSER_EXECUTABLE=/opt/google/chrome/chrome. Bundled Vite dev mode was needed for remote loading. Worker dev --share lacked permission; administrator added only private Serve HTTPS port 5733 to the dev web upstream. Original 8443–8448 mappings remain. The private link is in the local handoff, intentionally omitted here.
    • Paired the isolated app using its own newly minted one-time token. Explicitly selected its Default browser profile through the UI, loaded YouTube and clicked Sign in. The normal Google form rendered. Isolated browser PID 107893 executes /opt/google/chrome/chrome with user-data-dir /home/t3worker/.local/state/t3-browser-acceptance/userdata/server-browser/profiles/default; --no-sandbox is absent. The user now has control. No credentials/cookies were imported and browser inspection is paused during credential entry.
    • The dev runner automatically bootstrapped an empty project/thread record in its isolated database. No provider turn/message was submitted and no additional agent or delegated chat was started.
    • Validation: 22 focused tests pass across PreviewBrowser and ServerBrowserContexts; final format, lint and git diff --check pass. Earlier stale validation jobs were confirmed still running and explicitly cancelled. A fresh check:changed passed format, lint and GraphQL generation, but its parallel typecheck/knip/test processes exhausted available memory and were stopped. Those interrupted steps are not passes. No validation processes remain. Logs: /tmp/t3code-browser-tests-final.log and /tmp/t3code-browser-check-resume.log on the VPS. Existing required Vite+/Node tooling was retained; scripts/tests were launched through Bun where applicable, with no dependency or lockfile migration.
    • Original live server PID 2471299 and browser PID 2655938 retain their start times and installed paths. No live T3/browser restart, binary overwrite, data clearing, or session copying occurred. All browsing computation remains on the VPS.

    Exact next step: after the user finishes the direct Google sign-in and releases control, verify the intended account, perform an agent interaction, then close/reopen a tab explicitly in this isolated Default profile and verify authenticated continuity. If Google rejects it, record the visible rejection without account identifiers or authentication query parameters; do not call the executable override a login fix. Typecheck and knip still need a resource-bounded run before this candidate is considered fully checked.

    The isolated preview remains running for that acceptance step. Its launcher PID file and logs are under /home/t3worker/.local/state/t3-browser-acceptance/. Cleanup must target only its recorded processes. Administrator route rollback is tailscale serve --https=5733 off; do not reset Serve. The separately installed Chrome package can be removed with apt-get remove google-chrome-stable after stopping only this test browser. Do not autoremove packages or alter the live browser as part of cleanup.

  3. OsirisMedici commented on Oct 28, 2026

    @OsirisMedici
    OwnerAuthor

    Note

    🤖 Codex responding on behalf of OsirisMedici

    Google sign-in, account identity and authenticated tab-reopen continuity now PASS in the isolated VPS source instance. The installed live T3 runtime is unchanged, and this issue remains open for the remaining acceptance and validation work.

    • The user confirmed direct Google sign-in was complete. Through Codex's in-app Browser, inspected T3's shared VPS browser. YouTube displayed its signed-in Premium interface. Its account popup stayed at a loading indicator, so navigated normally to https://www.youtube.com/account; the rendered settings page explicitly showed a signed-in account and the channel Osiris Medici. Private email is omitted from this report.
    • Closed that task-owned T3 browser tab, opened a fresh Browser surface explicitly selecting Default, and navigated to the same account settings page. The same signed-in account/channel rendered without another login. This proves closing/reopening tabs within the running persistent context, not browser-process restart or cross-device persistence.
    • Codex successfully forwarded a click and navigation through the shared browser UI. Finally clicked Release control and verified T3 changed to Watching, with Take control available and remote navigation/input disabled. The authenticated tab remains open for the next step.
    • This is not yet a native T3-agent MCP acceptance test. This Codex chat exposes no T3 preview MCP tools. Source inspection confirms ordinary external MCP clients do not receive the preview capability. No other agent's bearer credential was borrowed, no capability checks were bypassed, and no provider turn or additional delegated chat was started. The browser automation connection initially failed with browser.user is unavailable; resetting only its automation session restored inspection. Neither T3 nor Chrome was restarted.
    • Reverified isolated Chrome PID 107893, executable /opt/google/chrome/chrome, profile /home/t3worker/.local/state/t3-browser-acceptance/userdata/server-browser/profiles/default, and absence of --no-sandbox. Original installed server PID 2471299 and browser PID 2655938 retain their original start times.
    • Code remains clean on fix/server-browser-executable at published commit 9169bd3e50d6c094d9192cee318f2e4ae53b501c, matching its remote branch. Previous proof remains 22 focused tests plus format/lint/whitespace passes; typecheck and knip remain incomplete after the documented resource-pressure cancellation. No PR, merge, deployment or live configuration replacement.

    Exact next step: from an existing authorized agent session in this isolated T3 environment, call preview_status, identify the authenticated server/Default tab, and perform a read-only snapshot plus one benign interaction through T3's preview MCP tools. This must not borrow another session's credential or create a new delegated agent under the current constraints. Then complete typecheck/knip with enough isolated capacity or sequential resource bounds. Keep the existing signed-in profile; no second login is needed for the tab-reopen workflow already verified. Do not describe the live installation as fixed or assume that the executable override alone explains Google's policy decision.

  4. OsirisMedici commented on Oct 28, 2026

    @OsirisMedici
    OwnerAuthor

    Note

    🤖 Codex responding on behalf of OsirisMedici

    The remaining native T3-agent acceptance and local changed-file checks now pass for the isolated source candidate. The live installation has not been changed. This validates the candidate workflow; it is not a deployment.

    Native verification used one bounded read-only turn in the already-existing isolated bootstrap thread, not a new chat. The provider completed normally. I independently checked its local tool-call transcript against the reported results:

    • preview_status and t3_preview_list identified the isolated server browser.
    • Native preview_open explicitly selected profileId="default", reuseExistingTab=false. t3_preview_list confirmed runtime="server" and profileId="default" for the new tab.
    • preview_snapshot verified the authenticated public channel Osiris Medici. Private email and screenshots containing it are omitted.
    • preview_navigate navigated to YouTube home and back to account settings; the same authenticated channel remained available.
    • t3_preview_close closed only the agent-owned tab_3_55adc489-bc79-47e1-9a33-41269a177dd8. A fresh explicit-Default open returned tab_4_55adc489-bc79-47e1-9a33-41269a177dd8; its native snapshot verified the same authenticated channel without another login. That final tab is left open. Other tabs were untouched; human control blocked no operations.

    Authentication, native agent interaction, and native close/reopen continuity therefore PASS. This does not establish browser-process restart or cross-device persistence, Instagram access, or a general guarantee that Google will accept every browser/account/network combination.

    All steps selected by check:changed passed against the same three changed files and base 0f4d050edee976297cb3886c0b2b07fc6937b3f3:

    Check Result Duration
    Format PASS 0.7 s
    Lint PASS 1.0 s
    Knip 1/2 PASS 20.3 s
    Knip 2/2 PASS 60.4 s
    Server GraphQL generated sources PASS 1.4 s
    Typecheck, server and scripts packages PASS, 2/2 successful 53.5 s
    Changed test file PASS, 13 tests 18.9 s

    The earlier focused PreviewBrowser + ServerBrowserContexts run passed all 22 tests. No source changed after that run. git diff --check and the final clean-tree check pass. Full CI suites and build were not run, and are not claimed as passed.

    To avoid repeating the memory-pressure failure, I ran a temporary ignored .t3/check-sequential.ts adapter copied from the repository runner. It retains the same file selection and step commands, executes steps sequentially, limits package typecheck concurrency to one, and uses a separate cache. The committed runner is unchanged. The run completed with exit 0 inside t3-browser-validation-9169bd3.scope, capped at 5 GB RAM and one CPU core, with approximately 4.37 GiB peak memory. Typecheck emitted advisory Effect suggestions but exited successfully. The ordinary parallel runner was not rerun. Bun launched the adapter; Node remained necessary for the existing T3 CLI because Bun rejects its node:sea import.

    Evidence is on the VPS under /home/t3worker/.local/state/t3-browser-acceptance/: check-sequential.log, native-agent-result.json, and the sanitized native-tools-proof.json. The native transcript is /home/t3worker/.codex/sessions/2026/10/28/rollout-2026-10-28T17-25-21-01a1838b-856b-7810-ba57-97cd8ae5b4da.jsonl; it may contain private account text, so do not publish it wholesale.

    Source is still clean on fix/server-browser-executable at published commit 9169bd3e50d6c094d9192cee318f2e4ae53b501c. No additional source commit, PR, merge, or deployment. The original live server PID 2471299 and browser PID 2655938 retain their original start times. The isolated backend PID 60214 and sandboxed full Chrome PID 107893 also remained running throughout native verification and validation.

    Only the task-owned development frontend was stopped to free over 5 GB for checks. A bundled-mode restore exceeded its own 3 GB limit and was killed within that unit. It was then restarted in unbundled mode as transient user unit t3-browser-acceptance-web.service with a 3 GB memory cap, one CPU core and a 2 GB Node heap. The existing private HTTPS route still points to the isolated web port 5733; the backend remains loopback 13773. The original live service/browser, browser binary, data and Serve mappings were not replaced or cleared.

    Final preview acceptance: Codex's in-app Browser renders the restored isolated app and the completed native agent report. The private HTTPS route returns 200. The unbundled frontend is active at about 1 GB current memory; initial cold loading took time, and earlier bundled restore errors remain in browser diagnostic history. The transient frontend unit can be stopped with systemctl --user stop t3-browser-acceptance-web.service. Stopping that unit does not stop the separate isolated backend/browser. The existing live server/browser and isolated backend/browser retain their original start times.

    The candidate is ready for review and a separate deployment decision. Do not point the live installation at this test home or copy its authenticated profile. No production rollout is authorized by this verification request.

  5. OsirisMedici commented on Oct 28, 2026

    @OsirisMedici
    OwnerAuthor

    Note

    🤖 Codex responding on behalf of OsirisMedici

    The user explicitly authorized applying the browser change to the live VPS setup with backup and rollback. The live server is now running the patched exact-3770 candidate. Existing chat data and the pre-existing GitHub authentication were preserved.

    • Avoided deploying the older prototype base. Used the installed release tag v0.1.4-nightly.20261027.3770, whose source is 7c3b3b3605efa695e9948051b569937fc1482c0f, and applied only the three browser-override files. Published clean branch fix/live-3770-browser-executable at 7911191adf758686c9238be7b27aaa4321bfe642. The original prototype branch is intact.
    • Built a distinct runtime 0.1.4-nightly.20261027.3770+osiris.browser.1 with pinned Node 26.12.1. Retained the original 3770 client, native runtime dependencies and resource monitor, and preserved the original vendor build configuration. Binary SHA-256 is 8a0f17406b220e90a025701cdd971c88bb4834725cb29b162ae7c181f88e6b67. The source manifest was restored after build stamping; the worktree is clean.
    • The exact-release patch passed all 22 focused browser tests. Sequential changed-file checks passed format, lint, both knip passes, GraphQL validation, typechecks for three affected packages, and 13 changed-file tests. No full CI suite is claimed. The packaged candidate also passed an isolated startup smoke test. Running its migration source against a SQLite snapshot required zero migrations.
    • Confirmed there were no active runs, stopped the live service, and made a cold backup before changing the runtime selection. Private backup root: /home/t3worker/.local/state/t3-live-rollouts/20261028-browser/. cold-backup/t3-core.tar is mode 0600 under a mode-0700 parent, 1,387,735,040 bytes; SHA-256 e6a2e9af4eeaeb60a0ee9a55003a55a9cf38690e88f8f294ddf931cb2ded88b6. It contains the cold userdata/profile, service environment/state, original launcher/runtime and original headless-shell files. It stays on the VPS; do not publish or transfer it as a source artifact.
    • The controlled restart selected the new runtime through service state plus one scoped systemd drop-in, ~/.config/systemd/user/t3code.service.d/90-osiris-server-browser.conf, setting T3CODE_SERVER_BROWSER_EXECUTABLE=/opt/google/chrome/chrome. The original main service unit is byte-identical to its backup. The server still uses loopback 3773 and the existing ~/.t3/userdata and Default-profile paths. No browser profile was cleared, replaced, or imported from the isolated test environment.
    • After startup, database integrity passed, schema matched the cold baseline, and all 32 pre-existing thread IDs/titles and all 542 pre-existing messages were verified preserved. Message payload hashes were checked, not only counts. Later verification adds messages to the existing investigation chat; it creates no new chat.
    • Live listener PID 477797 runs the staged binary; Chrome PID 486626 runs maintained full Chrome with sandbox enabled and the original /home/t3worker/.t3/userdata/server-browser/profiles/default directory. Service is active with no unexpected automatic restart. The prior server/browser were deliberately stopped once for the authorized cutover.
    • A native T3-agent turn in the existing Fresh diagnosis: T3 browser and VPS workflows chat verified GitHub OsirisMedici before and after closing/reopening a fresh server/Default tab without login. This validates preservation of the pre-deployment authenticated session across the service/browser restart.
    • Live YouTube was initially signed out, and the user then signed in directly in the live profile. No login data was copied from the isolated browser. T3 retained a human-control flag on the old tab despite the user's release confirmation, so the agent left that tab untouched and verification uses its own fresh tab in the same persistent profile.
    • Live Google/YouTube authentication and native tab-reopen persistence PASS. The agent opened tab_3_9a50cd4f-779e-47eb-9f01-a63781240864, verified public channel Osiris Medici, closed only that own tab, opened tab_4_9a50cd4f-779e-47eb-9f01-a63781240864, and verified the same channel without login. t3_preview_list confirmed both as server/Default. Native tools were preview_open, t3_preview_list, preview_snapshot, and t3_preview_close. The final authenticated agent tab remains open, and the old human-controlled page was untouched.

    Rollback is prepared and its readiness dry-run passed. T3 startup cleanup removed the old runtime directory from its managed versions folder. The verified cold archive was therefore used to retain an independent original runtime under rollback-original/, outside that cleanup. The rollback script validates this original executable, restores missing original runtime directories while the service is stopped, restores the saved original runtime selection, removes only the task-owned browser drop-in, reloads systemd and checks the original 3770 listener. It does not restore an old database or overwrite the current browser profile, so newer chats/sign-ins are not discarded by runtime rollback.

    Run through the user's existing SSH alias:

    ssh hostinger-t3 'python3 /home/t3worker/.local/state/t3-live-rollouts/20261028-browser/rollout.py --rollback --dry-run'
    ssh hostinger-t3 'python3 /home/t3worker/.local/state/t3-live-rollouts/20261028-browser/rollout.py --rollback'

    The second command is the rollback action, not a verification step. An actual live rollback was not executed unnecessarily. Emergency full-data replacement is a separate destructive recovery procedure and must not extract the cold archive over newer userdata. ROLLBACK.txt, manifests, checks, build/deploy logs and native verification results are in the same private rollout directory.

    A dedicated private Tailscale HTTPS mapping on unused port 8449 was added for live UI verification; existing mappings remain. Its exact private URL was delivered only in the local chat. Route removal, if requested, is tailscale serve --https=8449 off through the administrator alias; never reset Serve. The isolated acceptance backend/browser remain separate and their development frontend has been restored.

    The runtime is a local patch to nightly 3770. Future upstream updates need review for this override implementation. Browser-process restart persistence for the newly created live Google session and cross-device persistence are not claimed. No PR or merge was opened.

  6. OsirisMedici commented on Oct 28, 2026

    @OsirisMedici
    OwnerAuthor

    Note

    🤖 Codex responding on behalf of OsirisMedici

    Before/after evidence for the upstream contribution:

    Before: bundled headless shell After: selected full Chrome on the VPS
    Manual Google sign-in rejected in T3 while the user had control Native T3 server browser displaying the authenticated public channel with owner controls

    The before image is the original user-supplied rejection screenshot, cropped to remove the sign-in URL and surrounding chat. The after image is a new, unedited native preview_snapshot(save=true) capture of the public channel's Posts view. It shows Customise channel and Manage videos, and omits account email, private playlists, authentication URLs and notification contents. No screenshot pixels were synthesized.

    Both observations are from the Linux VPS workflow. Before used bundled Chrome Headless Shell 156.0.8078.70 on nightly 3770; after used maintained full Chrome 156.0.8078.73 with the executable override on the patched same-release base. The user signed in directly. Native T3 tools verified authenticated tab-reopen continuity, and the existing GitHub session survived deployment. This is an observed result on this host, not proof of Google's rejection cause or a guarantee of sign-in on every account or host.

    The contribution branch is based on upstream 30eb7e7bb1ef103fdd6f54081b6a4acf66b3ee4c: feat/server-browser-executable. The live deployment branch and backup remain separate.

  7. OsirisMedici commented on Oct 28, 2026

    @OsirisMedici
    OwnerAuthor

    Note

    🤖 Codex responding on behalf of OsirisMedici

    The live Google/YouTube browser workflow is verified, and the upstream contribution is now open: pingdotgg/t3code#26595.

    The PR leads with the original Google rejection and the native T3 screenshot showing the authenticated public channel and owner controls. It includes setup/service documentation, scope, regression tests, and explicit acceptance limits. Both uploaded images were checked in the rendered PR.

    • Contribution: feat/server-browser-executable, commit 9fc8a2e60c68123e88da268e6b0debe6c8e45899; clean VPS checkout /home/t3worker/projects/t3code-contribution-browser. Three changed source/documentation files; screenshots are GitHub attachments, not repository assets.
    • Checks: red/green regression confirmed; 22 focused tests pass; formatting, lint, whitespace and first knip pass pass. Remaining local changed-file checks stopped under VPS memory pressure and are not claimed as passes. Upstream checks/review are pending.
    • Live deployment remains the previously verified patched 3770 build, source 7911191adf758686c9238be7b27aaa4321bfe642. The contribution head was not deployed. Existing chats and shared Default sessions remain in place; the live service is active.
    • Private backup and rollback remain at /home/t3worker/.local/state/t3-live-rollouts/20261028-browser. The rollback dry-run passed; rollback retains current chats/profile. No rollback was run unnecessarily.
    • The unused isolated acceptance backend/browser were stopped to release resources; their data/profile were retained. No live process was stopped for this contribution.

    Next step: resolve upstream CI/review on pingdotgg#26595. No merge or additional deployment is authorized. Process-restart persistence of the newly created Google session and non-Linux runtime acceptance remain untested; tab close/reopen persistence and native agent interaction passed on the live Linux instance.

  8. OsirisMedici commented on Oct 28, 2026

    @OsirisMedici
    OwnerAuthor

    Note

    🤖 Codex responding on behalf of OsirisMedici

    PR review follow-up: pingdotgg/t3code#26595 now includes commit d0fba2c7a9d309fe3efd2dfbca36b90cfd16e730 on feat/server-browser-executable. The contribution checkout is clean at /home/t3worker/projects/t3code-contribution-browser. The branch is now synced with upstream 9e09926d97824179d97311d1a810c6b5bb60d2d1 at head b1a1d26008b8146ae2ee38cbcf63b8c5a4e9cc71. There are no commits behind the base. The browser source/tests are unchanged by this sync; the focused tests were repeated with 30 passes and 3 browser-dependent skips, and scoped whitespace checks passed.

    Confirmed and fixed the review finding: an invalid executable override now fails HTML publication with the configuration error, cleans up its attachment and leaves no recoverable reference. An unset browser remains optional. Reply and regression evidence. The original review thread is resolved.

    Checks on the follow-up: 30 focused tests passed; 3 existing browser-dependent tests skipped without a test browser. The extended invalid-path cases and added HTML-publication regression failed before this fix. Formatting, lint, whitespace, the first knip pass and server GraphQL generation passed. Knip exports checking exhausted its worker heap. The sequential job was capped at 3 GiB with no swap and one CPU; it terminated during typechecking as memory pressure rose and was stopped. No validation job remains running.

    The user guide and PR description are updated. Both original before/after images still render at the top and are explicitly identified as evidence from the earlier patched-release acceptance, not a new live deployment.

    Blocker and exact next step: a maintainer must approve the fork's GitHub Actions runs, including CI for this PR. The required test/build checks have not run. After approval, inspect those results and current-head reviews, then fix any real findings on this branch. Do not call the PR fully green before those checks run.

    The live service, installed runtime, browser profile, chats and sessions were not changed or restarted. Nothing was merged or deployed. The earlier private backup/rollback plan remains in place.

  9. OsirisMedici commented on Oct 28, 2026

    @OsirisMedici
    OwnerAuthor

    Note

    🤖 GPT-6.1 Sol responding on behalf of OsirisMedici

    Resolved for the fork's live VPS installation. The recorded live deployment acceptance verified direct Google sign-in followed by native T3-agent YouTube account access and fresh server/Default-tab close/reopen continuity without another login on 0.1.4-nightly.20261027.3770+osiris.browser.1. The pre-existing GitHub session and original chats were preserved through that controlled deployment.

    Closing this local Google/YouTube rejection report on that evidence; this is not a new authentication test. Google-session persistence across a further browser-process restart, cross-device continuity, and Instagram acceptance are not claimed and remain tracked in #1. The separate upstream contribution pingdotgg/t3code#26595 remains subject to upstream CI/review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions