How to build a browser video editor with OpenAI Codex

Rule of thumb: if your users are editing their own short clips (a minute or two, on ordinary hardware) the browser handles it and you never see a compute bill, which makes owning the editor the obvious call. If your product processes long or high-resolution files, or has to render hundreds of videos without anyone present, rent the rendering, because a laptop tab is the wrong machine for that job. The middle case is a product that mostly does short clips and occasionally does not, and the honest answer there is to build the editor and set a file-size ceiling you are comfortable defending.

* What you store is source files people chose to keep and the exports they made, so the number depends entirely on whether you keep either. Supabase Free includes 1 GB of file storage and 5 GB of egress a month. Pro, from $25/mo, includes 100 GB of storage and 250 GB of egress, then charges $0.0213 per GB stored and $0.09 per GB served. Deleting an export a week after it was downloaded is the single cheapest decision available here, and it belongs in your retention rule rather than in a bigger plan.

Whichever column you pick, the running cost afterwards is storage and hosting rather than compute, and it stays that way whether ten people or ten thousand are exporting, because every one of them brings their own processor to the job.

Prices and rates from supabase.com, developex.com and learn.chatgpt.com, checked August 2026.

Nothing here is worth memorizing. These four just need to exist on your machine. From step 01 on, you say what you want and Codex runs the commands.

1. 01

   Write AGENTS.md before anything is scaffolded

   Codex loads AGENTS.md at the start of every task, so the rule that matters most on this build (nothing is uploaded for processing) is loaded before there is any code to violate it.

   PromptSet up the projectCopy

   Start by writing an AGENTS.md at the project root: the stack is React 18, Vite, TypeScript, Tailwind, and the Supabase JS client, and this project is a browser video editor. Fix the vocabulary (projects, videos, clips, exports) and record the standing constraint that all video processing happens client-side through FFmpeg compiled to WebAssembly, so no task should ever add a server-side transcode. You load that file automatically at the start of every later task. Then scaffold the project: a typed Supabase client under src/lib reading VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from .env, with .env confirmed present in .gitignore. Start the dev server once to prove it boots.

   The no-server-transcode line is the one worth writing down. It is a reasonable-sounding thing for any assistant to suggest later, and it would quietly reintroduce the cost this whole build exists to avoid.

2. 02

   Have Codex prove the encoder before anything depends on it

   One task, one throwaway page, one trimmed file. Read the diff and then actually run it against a large video. This is the step where you learn what your practical ceiling is.

   PromptGet FFmpeg running in the browserCopy

   Add @ffmpeg/ffmpeg and @ffmpeg/util and build a single throwaway page that proves in-browser encoding works end to end: pick a local video file, enter a start and end time, press a button, and get a trimmed file back as a download. Use the single-threaded @ffmpeg/core loaded via toBlobURL so the CDN assets are not blocked by CORS, and surface the real ffmpeg progress events. When it works, tell me what you observe about load time, memory, and how the browser behaves on a file over about a gigabyte.

   Ask for observations, not just code. What you want out of this task is a number for your file-size ceiling, and the only way to get it is to run the thing.

3. 03

   Give the timeline its own task, and read that diff closely

   The timeline is the largest single piece of interactive code in the build. Keep it in one task, and read what comes back rather than approving it on trust.

   PromptBuild the timelineCopy

   Build the editor screen as its own task. A horizontal timeline of clips laid end to end, each one draggable to reorder and trimmable from both edges, with a playhead, a second-by-second ruler, and a preview above that follows the playhead while scrubbing. Hold the timeline in a single source of truth so every clip’s in-point, out-point, and position derive from it, and nothing is tracked in two places. Use placeholder clips. The encoder and the database get wired in afterwards. Walk me through the state shape before you build the components on top of it.

   Asking for the state shape first is worth the extra round trip here. Almost every timeline bug is a state bug, and they are far cheaper to catch in a description than in a diff.

4. 04

   Narrow permissions, then add accounts and the data model

   This task touches authentication, which is exactly the kind of change worth scoping Codex down for rather than leaving whatever settings you use for routine edits.

   PromptAdd auth, projects, and access rulesCopy

   This task touches authentication, so narrow your permissions to just this one. Wire in Supabase Auth for email-and-password sign-up, login, logout, a persisted session, a profiles row per account, and a useUser hook. Then write the migrations: projects owned by a user, videos belonging to a project, and exports recording each finished render with its settings. Add an app_role enum of 'visitor', 'user', and 'admin' with a user_roles table kept off the account itself, since anything stored there is editable by its owner, plus a SECURITY DEFINER has_role function. Finish with row-level security on all three tables: a user reaches only their own rows, an admin reaches everything, and every insert and update carries an explicit WITH CHECK. Show me the SQL before it runs, and walk me through proving a second account comes back empty.

   The ownership rule here is simpler than on most templates, which is exactly why it should be watertight. No complicated case exists to hide behind.

5. 05

   Connect the timeline to the encoder

   The two halves you built separately now become one product. Codex only needs the timeline state and the encoder hook for this, not the whole project.

   PromptBuild the export flowCopy

   Wire the timeline into the encoder. An Export action should translate the timeline state (the trims, the clip order, and the selected aspect ratio) into an ffmpeg invocation, run it in the browser with real progress reporting, and return a file. Offer widescreen, vertical, and square as fixed presets rather than free-form cropping. On completion, write a row to the exports table with the settings and the output duration, and generate a local thumbnail per clip. Handle the ugly cases explicitly: an oversized file, an unsupported input format, and a tab that runs out of memory partway through.

6. 06
   Destination

   Hand the last pieces to a cloud run, then test it yourself

   Demo mode and the admin view are self-contained and well specified, a reasonable pair to hand to a cloud run while you do something else, provided you read the diff before it merges.

   PromptAdd demo mode, admin, and testCopy

   Two remaining pieces, both self-contained. First, demo mode: a signed-out visitor gets a throwaway workspace with a sample clip, backed by separate demo tables so nothing they touch is real. Second, an admin view of storage used, exports run, and accounts, reachable only by the admin role. When they are in, run the app and take it end to end yourself: open the demo signed out and cut the sample, sign up, import a real file, trim and reorder it, export vertically, and confirm the export shows up in both the dashboard and the admin view, then fix whatever does not hold up.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

The one rule that matters: the database service key, and any AI provider key you add later, never go into the app or a public repo. If one gets out, treat it as compromised and rotate it the same day.

Pick on two things here rather than one. The usual question is whether the plan allows commercial use. Vercel’s Hobby tier does not. The one specific to this build is whether the host lets you set custom response headers, because the faster multithreaded encoder needs them and the default single-threaded one does not. Building on the default and keeping the option open is the sensible order.

Add a "Generate captions" action on the editor that extracts the audio track from the current cut, sends it to a server-side function that calls a speech-to-text model, and returns timed segments. Render them as an editable caption track on the timeline that the user can fix before burning them into an export, and keep the audio out of long-term storage once the transcript comes back.

Add a "Tighten this" action that analyses the transcript and the audio levels for long pauses, filler, and dead air, then proposes a set of cuts as a preview the user accepts, adjusts, or rejects on the timeline. Never apply them automatically, and always leave the original clip intact so the change can be undone.

Add a panel on the export screen that sends the transcript to your ai function and returns a suggested title, a short description, and a handful of tags, sized for wherever the user says they are publishing. Present them as editable drafts rather than final copy, and let the user regenerate any one of them on its own.

Add a "Suggest a thumbnail" action that pulls several candidate frames from the finished cut (avoiding blur, blank frames, and mid-blink shots) and offers them as a row the user picks from, with the option to scrub for their own frame instead. Generate the candidates on the device using the frames you already have, so no video leaves the browser for this.

Each prompt above should pick whichever model tier fits the job: a fast, lower-cost model for high-volume work, and a stronger reasoning model for anything that weighs tradeoffs against each other. Codex’s model names change faster than this page does, so check OpenAI’s current model line-up (linked in the references below) before you build, rather than copying a name you saw once. Keep all of it behind that same ai function, so one key and one rule set covers every feature you add.