Reverse Engineering ChatGPT’s Frontend: A Deep Dive into Webpack Archaeology
Hook
While OpenAI keeps a tight lid on ChatGPT’s development roadmap, one clever repository has been systematically archiving frontend webpack bundles—creating a public record of ChatGPT’s client-side evolution through methodical reverse engineering.
Context
Modern SaaS companies rarely document their incremental changes. Features appear and disappear, UI elements shift, and new capabilities emerge without changelogs or release notes. For developers trying to understand how products evolve—whether for security research, competitive analysis, or simple curiosity—this opacity is frustrating.
ChatGPT Source Watch, created by developer 0xdevalias, addresses this gap through a forensic approach: systematically archiving ChatGPT’s webpack chunks from OpenAI’s CDN and maintaining a human-curated changelog of observable changes. It’s less a traditional tool and more a methodological blueprint for monitoring any webpack-based single-page application. The repository demonstrates that with browser DevTools, a handful of Node.js scripts, and methodical documentation, you can create a surprisingly effective window into a proprietary product’s evolution.
Technical Insight
The architecture is deliberately low-tech but effective. At its core, the workflow involves extracting script URLs from ChatGPT’s HTML using browser DevTools, filtering for new chunks that haven’t been archived, downloading them, and then unpacking and formatting the files for human-readable diffs.
The extraction process starts in Chrome DevTools Console with a simple DOM query:
const scriptTags = document.querySelectorAll('html > head > script');
const urls = Array.from(scriptTags).map(tag => tag.src).filter(Boolean);
console.log(urls);This outputs all script URLs loaded in the page head. The real intelligence comes in the filtering and normalization pipeline. The filter-for-unsaved.js script reads these URLs from stdin and cross-references them against the local orig/ directory, outputting only genuinely new chunks. This prevents duplicate downloads and keeps the archive clean.
The repository maintains two parallel directory structures: orig/ contains pristine, unmodified webpack chunks exactly as served by OpenAI’s CDN, while unpacked/ holds normalized, formatted versions. This dual approach is crucial—the originals preserve forensic integrity, while the unpacked versions enable meaningful diffs between builds.
The normalization happens via unpack-files-from-orig.js, which copies files from orig/ to unpacked/, strips version hashes from filenames and directory names (making cross-version comparisons feasible), and runs Biome formatter on the JavaScript. Webpack chunks are notoriously difficult to read—minified, hash-suffixed, and structurally inconsistent between builds. By removing hashes and applying consistent formatting, the tool transforms opaque bundles into diffable artifacts.
The buildmanifest-to-json.js script handles another common problem: webpack build manifests aren’t always human-readable. This script converts them to JSON and can extract and prefix asset URLs. According to the README, you invoke it with either a build hash or full URL to a _buildManifest.js file:
./scripts/buildmanifest-to-json.js <build-hash> --extract-urls
# Or with a full URL
./scripts/buildmanifest-to-json.js <url-to-buildmanifest> --extract-urlsPerhaps the most valuable component isn’t code at all—it’s the manually curated CHANGELOG.md. This file documents observed changes across builds, providing a public record of ChatGPT’s frontend development timeline. The filter-urls-not-in-changelog.js script helps maintain this by identifying URLs that haven’t yet been documented, ensuring nothing slips through the cracks.
For those seeking historical data not yet archived, the README wisely points to the Wayback Machine, which has captured snapshots of OpenAI’s CDN at various points. This acknowledges a fundamental limitation: the repository can’t retroactively capture what wasn’t archived in real-time, but external services can fill some gaps.
Gotcha
This is emphatically not a turnkey solution. The workflow requires significant manual intervention—you’re running DevTools queries, piping outputs through scripts, manually downloading chunks, and interpreting diffs yourself. The README explicitly notes that “detailed documentation is not provided” for the scripts and that users must “carefully read and comprehend the contents of each script” before executing them. There’s no daemon watching for changes, no automated alerting when new builds drop, no CI pipeline generating reports. It’s a set of power tools for investigators, not a monitoring service.
The analysis is also strictly limited to frontend code. You can see new React components, routing changes, and client-side feature flags, but you’re blind to backend logic, model updates, API schema changes, or server-side feature toggles. If OpenAI rolls out a new capability purely through backend changes or model improvements without touching the webpack bundles, this approach won’t detect it. You’re fundamentally constrained by what gets shipped to the browser.
The repository also depends on OpenAI’s continued use of webpack and their current CDN structure. A migration to Vite, Turbopack, or a different bundler would require retooling. The scripts make assumptions about URL patterns and file structures that could break with infrastructure changes. It’s reactive forensics, not a stable API.
Verdict
Use this if you’re conducting security research on ChatGPT’s frontend, tracking feature rollouts for competitive intelligence, documenting changes for compliance purposes, or building a corpus of ChatGPT’s evolution for academic research. The curated CHANGELOG.md alone is worth browsing—it serves as a public record of ChatGPT’s frontend development timeline. It’s also an excellent educational resource if you want to understand webpack bundle analysis or build similar monitoring for other SaaS products. Skip this if you need fully automated monitoring (the manual workflow won’t scale), backend or API analysis (you’re limited to frontend artifacts), real-time alerting (there’s no continuous polling), or official documentation (this is community-driven reverse engineering with no guarantees). It’s a niche tool executed thoughtfully for a specific investigative use case, and it excels within those constraints.
