Least-privilege GitHub access
LeetBridge uses a GitHub App so users choose which repositories it can access. GitHub host access is requested only when the user starts the connection flow.
Chrome extension case study
Turning accepted solutions into a portfolio-ready GitHub archive
LeetBridge automatically captures accepted LeetCode submissions and saves them to a repository selected by the user, including organized source files, problem documentation, and a browsable solution index.
Platform
Chrome, Manifest V3
Integration
GitHub App and REST API
Architecture
Client-side extension
Release
Chrome Web Store
Why I built it
Useful automation, with less access
I found existing Chrome extensions that synced LeetCode solutions to GitHub. I liked the convenience, but I was not comfortable giving a solution-syncing tool broad read and write access across my GitHub repositories when it only needed to save code in one place.
That led to the question behind LeetBridge: could I build the same workflow while letting users grant access to just one dedicated solutions repository?
I also wanted to understand how browser extensions are built. This was a chance to learn the full process, from extracting data from a live page to packaging and publishing something other people could install.
The solution
Make repository scope a design requirement
I chose a GitHub App so users can select only the repository they want to use, rather than needing to grant access to every repository. Keeping that scope narrow was a way to reduce unnecessary exposure, not a claim that any integration is risk-free.
LeetBridge listens for an accepted result, validates the submission, checks for duplicates, and writes the solution to the selected repository. It also generates documentation and supports resumable historical imports, keeping the convenience that drew me to the idea in the first place.
System flow
From accepted submission to documented repository
01
Detect
Observe an accepted result on a LeetCode problem page.
02
Validate
Extract the problem, language, code, and submission ID.
03
Authorize
Use the GitHub App's user-selected repository scope.
04
Publish
Write the solution and refresh generated documentation.
Engineering decisions
Designed for trust, recovery, and maintainable output
No developer-operated backend
Accepted code moves directly from the browser to GitHub over HTTPS. Credentials and settings remain in Chrome's extension storage on the user's device.
Resilient historical imports
Pagination, request pacing, retry cooldowns, and durable checkpoints let large histories recover from tab closures, service-worker restarts, and upstream rate limits.
Repository-ready output
Solutions are organized into predictable folders with per-problem documentation and a generated repository index that summarizes difficulty and language usage.
What I learned
From a personal security concern to a shipped product
- How browser extensions work
- I learned how Manifest V3 connects content scripts, a background service worker, and a popup through message passing. Separating page access from privileged operations helped me understand the responsibilities and lifecycles of each part.
- Scraping and structured data extraction
- I practiced DOM-based scraping and parsing submission responses to capture problem details, programming languages, submitted code, and acceptance status. Working with a dynamic page taught me to validate the data rather than rely on a single UI element.
- Authentication and permission boundaries
- I explored GitHub App authorization, repository-level access, local token storage, and optional browser permissions. A key lesson was that permission to contact a website and authorization to modify a repository are separate controls.
- Reliable API workflows
- Historical imports gave me practical experience with pagination, rate limits, retry cooldowns, duplicate detection, and saved checkpoints. I learned to treat interruptions as expected conditions and preserve progress for recovery.
- Packaging, publishing, and updates
- I took the project beyond a locally loaded extension by preparing icons, versioned ZIP packages, privacy disclosures, permission explanations, and a Chrome Web Store listing. Publishing also introduced the review process and the work involved in delivering follow-up updates.
Outcome
Shipped as a public Chrome extension with a complete onboarding and repository workflow
The finished product combines browser integration, authenticated third-party APIs, durable import state, generated documentation, privacy disclosures, and store-ready packaging in one focused user experience.