Inspiration
Closing the last tab in a Chrome window closes the entire window. It is a tiny default behavior, but it repeatedly breaks the flow of people who organize work across multiple windows, keep a dedicated workspace open, or simply close tabs quickly. Existing workarounds require remembering to keep a spare tab around.
I wanted the fix to feel invisible: no website access, no history access, no tracking, no account, and no cloud dependency. The extension should do one job, explain itself clearly when it appears, and then get out of the way.
What it does
LinkCubby watches each normal Chrome window. When only one real tab remains, it creates one inactive, pinned, local guard tab. The user can close the final real tab without losing the window. When more real tabs return, the guard is removed.
The guard provides three direct actions: open a new tab, open Options, or disable protection. Options includes enable/disable controls, clear local-only privacy messaging, offline supporter-license verification, and three local guard styles: Clean, Zen Image, and Advanced Custom. The free window-protection behavior is never paywalled.
The extension requests only Chrome's storage permission. It has no host
permissions, content scripts, analytics, remote code, or network license checks.
How I built it
The shipped extension is dependency-free Vanilla JavaScript, HTML, and CSS on
Chrome Manifest V3. A service worker reconciles tab and window lifecycle events
and enforces at most one extension-owned guard per normal window. Settings and
supporter state stay in chrome.storage.local.
Offline licenses use Web Crypto verification with ECDSA P-256. A separate Cloudflare Worker source handles Stripe webhook fulfillment and Resend email delivery. During Build Week I replaced nondeterministic signing with an RFC 6979 P-256/SHA-256 implementation so duplicate or retried payment events reproduce the same complete license key.
I also built a no-dependency Node test harness that executes the production background, Guard, Options, license verifier, and Worker code against isolated Chrome API, DOM, storage, and webhook fixtures. The current suite passes 7/7 extension tests and 10/10 Worker checks.
How I used Codex and GPT-5.6
I used Codex and GPT-5.6 throughout the Build Week extension as a product, engineering, and verification partner. Codex accelerated repository inspection, planning, UI implementation, deterministic-signing work, regression-harness development, documentation, security scans, and release checks.
I retained the product decisions: the free core must remain free; the extension must request only the minimum permission; it must not read sites or browsing history; and supporter customization must not weaken the core behavior. GPT-5.6 helped reason across lifecycle races, privacy boundaries, cryptographic determinism, UI states, and failure recovery. Fresh code review and visual QA then challenged the result rather than treating generated code as correct by default.
The project existed before the submission period. The meaningful Build Week work on July 14-15, 2026 was the complete Guard/Options visual rebuild, deterministic license signing, executable production-code regression coverage, expanded failure-state handling, and release evidence. Dated status, review, and screenshot artifacts distinguish this work from the earlier baseline.
Challenges I ran into
The hardest engineering problem was Chrome's event-driven lifecycle. Closing, moving, restoring, or detaching tabs can produce overlapping events, so the background logic has to converge safely instead of trusting a single event. The tests cover zero, one, and two real tabs, multiple windows, startup restoration, duplicate cleanup, disabling and re-enabling protection, and per-window isolation.
The second challenge was license idempotency. The first signing path could verify correctly while still producing a different complete key on retry. An independent review caught that gap. I implemented deterministic RFC 6979 signing and added repeat, fresh-module, official-vector, and Web Crypto verification tests.
The third challenge was proving a browser extension without broad permissions or fragile browser automation. I kept real Chrome screenshots for the visual states and built isolated executable mocks for deterministic regression coverage. A final manual unpacked-extension lifecycle pass remains part of the reviewer steps.
Accomplishments that I am proud of
- One focused utility with only the
storagepermission and no tracking. - A free core workflow that remains separate from optional supporter styling.
- Deterministic offline licenses without runtime network validation.
- Direct execution of production extension scripts in the regression suite.
- Responsive light/dark UI, reduced-motion support, and recoverable error states.
- Independent code review and Visual QA with no remaining P0, P1, or P2 findings.
What I learned
Small browser utilities become reliable only when their boundaries are explicit. The most valuable use of Codex was not writing more code; it was connecting the specification, implementation, edge-case tests, visual evidence, and release constraints into one traceable loop. Independent review was especially valuable: a license can be cryptographically valid yet operationally wrong if retries do not reproduce the same key.
What's next
Next I would complete the final unpacked Chrome lifecycle matrix, publish the repository and reviewer build, configure the production Stripe/Cloudflare/Resend accounts, replace the placeholder payment link, and prepare the Chrome Web Store release. A future hardening pass could replace the JavaScript BigInt signer with an audited constant-time primitive if the threat model expands.
Log in or sign up for Devpost to join the conversation.