How to Automate Video Creation with Claude Code or Codex Using Dropbox Assets and JSONClip

Long-read guide

A lot of teams already have the raw ingredients for automated video creation, but the pieces are scattered. The user assets live in Dropbox. The editing intent lives in someone’s head, a brief, or a Slack thread. A coding agent such as Claude Code or Codex can read instructions, transform files, write JSON, and run terminal commands. JSONClip can take the finished movie specification and render it. What is usually missing is the operating model that connects those pieces into one repeatable workflow.

This guide explains that operating model from start to finish. The central idea is simple: keep user assets in Dropbox, convert the shared links into machine-safe direct-download URLs, let Claude Code or Codex assemble the JSONClip movie structure, and render with curl. That sounds almost too simple, but the details matter. Link conversion matters. Manifest structure matters. Prompt structure matters. Validation matters. If you skip those pieces, the result is a brittle agent demo. If you get them right, the result is a practical automation pipeline.

The article uses a concrete asset pack with images, video clips, voiceover, music, subtitles, and a logo. It shows what the user assets file should look like, what the agent prompt should look like, what the normalized Dropbox URLs should look like, what the final JSONClip movie can look like, and how to render the output with one command. It also explains where Claude Code and Codex differ only lightly in practice, and why JSONClip is the rendering layer that makes the whole flow deterministic.

Why this workflow matters

Most creator teams do not fail at video automation because they lack imagination. They fail because their assets are trapped in a human-oriented storage workflow while the rendering layer expects machine-oriented URLs and explicit instructions. Dropbox is designed for sharing. Claude Code and Codex are designed for coding tasks in a terminal context. JSONClip is designed to render from explicit movie JSON. When those three layers are made to cooperate, the automation path becomes much shorter than people assume.

This is especially relevant when the input materials are user assets rather than a polished internal media library. User-delivered files are messy. Some arrive as portrait JPEGs, some as MP4s, some as voice notes, some as subtitle drafts. In a manual editor that usually means a human opens CapCut, Final Cut, or Resolve and improvises. In an automation-first workflow the agent does the orchestration work instead: normalize the links, map the assets to roles, create the render plan, and produce a repeatable output contract.

Why Dropbox is a good source for user assets

Dropbox is often already where the user assets live, especially in client services, UGC workflows, content studios, and internal marketing teams. That matters because the fastest automation stack is usually the one that respects the current asset path instead of forcing an extra upload portal before work can begin.

Dropbox also documents the exact direct-download behavior needed for machine fetching in its help page on forcing shared links to download. The practical rule is straightforward: if the share link contains `dl=0`, replace it with `dl=1`. If the link already has other query parameters such as `rlkey`, keep them. That one normalization step is what makes Dropbox-hosted assets usable by the render worker.

{
  "campaign_name": "Spring product teaser",
  "goal": "Generate a short vertical promo from user assets without editing by hand",
  "format": { "width": 1080, "height": 1920, "fps": 30 },
  "brand": {
    "headline": "Launch Faster With JSONClip",
    "cta": "See how automation works",
    "primary_color": "#ff2e97",
    "accent_color": "#0ea5e9",
    "font": "Avenir Next"
  },
  "dropbox_assets": {
    "cover_image": "https://www.dropbox.com/scl/fi/a111/cover.jpg?rlkey=cover111&dl=0",
    "detail_image": "https://www.dropbox.com/scl/fi/a222/detail.jpg?rlkey=detail222&dl=0",
    "hero_video": "https://www.dropbox.com/scl/fi/v333/hero.mp4?rlkey=hero333&dl=0",
    "cutaway_video": "https://www.dropbox.com/scl/fi/v444/cutaway.mp4?rlkey=cut444&dl=0",
    "voiceover_mp3": "https://www.dropbox.com/scl/fi/m555/voice.mp3?rlkey=voice555&dl=0",
    "music_mp3": "https://www.dropbox.com/scl/fi/m666/music.mp3?rlkey=music666&dl=0",
    "subtitles_srt": "https://www.dropbox.com/scl/fi/s777/captions.srt?rlkey=sub777&dl=0",
    "logo_png": "https://www.dropbox.com/scl/fi/l888/logo.png?rlkey=logo888&dl=0"
  }
}

Notice the input state here. The links are still in the user-facing Dropbox share format. That is common. It is also the exact point where many automation flows fail. A human clicks the link in a browser and it seems fine. The renderer hits the same link and gets preview behavior instead of direct media bytes. The agent needs to own that conversion step deliberately instead of assuming the render layer will guess what was intended.

from urllib.parse import urlparse, parse_qsl, urlencode, urlunparse

def force_dropbox_download(url: str) -> str:
    parsed = urlparse(url)
    query = dict(parse_qsl(parsed.query, keep_blank_values=True))
    query["dl"] = "1"
    return urlunparse(parsed._replace(query=urlencode(query)))

{
  "campaign_name": "Spring product teaser",
  "goal": "Generate a short vertical promo from user assets without editing by hand",
  "format": { "width": 1080, "height": 1920, "fps": 30 },
  "brand": {
    "headline": "Launch Faster With JSONClip",
    "cta": "See how automation works",
    "primary_color": "#ff2e97",
    "accent_color": "#0ea5e9",
    "font": "Avenir Next"
  },
  "dropbox_assets": {
    "cover_image": "https://www.dropbox.com/scl/fi/a111/cover.jpg?rlkey=cover111&dl=1",
    "detail_image": "https://www.dropbox.com/scl/fi/a222/detail.jpg?rlkey=detail222&dl=1",
    "hero_video": "https://www.dropbox.com/scl/fi/v333/hero.mp4?rlkey=hero333&dl=1",
    "cutaway_video": "https://www.dropbox.com/scl/fi/v444/cutaway.mp4?rlkey=cut444&dl=1",
    "voiceover_mp3": "https://www.dropbox.com/scl/fi/m555/voice.mp3?rlkey=voice555&dl=1",
    "music_mp3": "https://www.dropbox.com/scl/fi/m666/music.mp3?rlkey=music666&dl=1",
    "subtitles_srt": "https://www.dropbox.com/scl/fi/s777/captions.srt?rlkey=sub777&dl=1",
    "logo_png": "https://www.dropbox.com/scl/fi/l888/logo.png?rlkey=logo888&dl=1"
  }
}

Once the links are normalized, the rest of the stack becomes much cleaner. The agent is no longer reasoning about “Dropbox” as a special integration. It is reasoning about a clean asset manifest with reachable URLs. That is the level you want if you care about repeatability.

What Claude Code and Codex are doing here

Anthropic describes Claude Code as a terminal-native coding tool that can plan, edit files, and run commands. OpenAI positions Codex around common coding workflows such as analysis, integrations, and code generation. For this workflow, that distinction matters less than people think. Both tools are useful because they can work inside a real project directory, write concrete files, and execute validation commands.

In other words, the job is not “ask an AI model for marketing advice.” The job is “have an agent read a structured asset manifest, generate build artifacts, and run a predictable render command.” That is a coding task. A terminal agent is the correct shape for it.

The asset-manifest pattern is the real unlock

The most important structural choice is not the brand style or the transition set. It is whether the user assets arrive in one structured manifest that the agent can trust. If you hand the agent ten raw URLs and a vague instruction like “make a promo,” the result will drift. If you hand the agent one machine-readable file with asset roles and brand context, the result becomes much more stable.

• The manifest should say what each asset is, not only where it is.
• It should distinguish cover stills, hero clips, cutaway clips, voiceover, music, subtitles, and logos.
• It should include the intended format, headline, CTA, and any obvious editorial constraints.
• It should be versionable so the agent can regenerate output when a user swaps one asset or updates the subtitle file.

This is why the example manifest above includes brand values and campaign intent, not just URLs. The agent should not have to infer basic framing from scratch every time. It should spend its attention on sequencing and rendering, not on guessing what role the voiceover file plays.

A clean Claude Code workflow

The Claude Code version of this workflow is deliberately boring. That is a good thing. The operator adds the manifest to the repository, drops a prompt file next to it, and runs one terminal command. Claude Code reads the project, rewrites Dropbox links, builds the movie JSON, writes the render script, and documents its choices.

Use the file assets/user_assets.json as the source of truth.

Tasks:
1. Convert every Dropbox shared link to the direct-download form with dl=1.
2. Create build/normalized_assets.json.
3. Create build/movie.json for a 16-20 second 1080x1920 JSONClip render.
4. Use these assets:
   - cover_image as opening hook
   - hero_video as the main section
   - detail_image as a reinforcement scene
   - cutaway_video as motion variation
   - voiceover_mp3 as voiceover
   - music_mp3 under the voiceover with ducking
   - subtitles_srt as captions
   - logo_png near the ending CTA
5. Keep the pacing simple and readable. Do not overuse effects.
6. Add 2-3 transitions, short text overlays, and a clean CTA ending.
7. Save a runnable curl command in build/render.sh.
8. Validate that the generated movie only references direct Dropbox URLs.
9. Do not invent assets that are not in the manifest.

Output files:
- build/normalized_assets.json
- build/movie.json
- build/render.sh
- build/notes.md summarizing what you chose and why

This prompt is not trying to sound clever. It is trying to be operational. That matters. Good agent prompts for production work are scoped, boring, and explicit. They define input files, required output files, asset mapping rules, and validation rules. The more your prompt reads like an execution brief and the less it reads like a brainstorming request, the more reliable the output becomes.

Claude Code is especially comfortable in this pattern because the task is strongly file-oriented: inspect manifest, create normalized manifest, write movie JSON, write shell script, write notes. The agent can treat each file as a concrete deliverable instead of trying to keep the whole workflow in one chat window.

A clean Codex workflow

The Codex version is almost the same. That is the useful truth here. If your asset contract is solid, the agent prompt becomes portable. The phrasing can differ slightly, but the files and outputs should stay the same. That means the workflow is not trapped inside one model vendor. That is exactly what mature teams want from an automation path.

Read assets/user_assets.json and prepare a complete JSONClip render package.

Requirements:
- Rewrite every Dropbox URL to dl=1.
- Build a vertical promo around the provided user assets only.
- Generate build/movie.json, build/normalized_assets.json, and build/render.sh.
- Use one hook image, two short video sections, voiceover, music, subtitles, and a closing CTA.
- Keep the structure API-friendly and deterministic.
- Prefer simple strong editorial choices over decorative complexity.
- Add a brief build/notes.md that explains scene order, transitions, and effects.
- Verify there are no remaining Dropbox links with dl=0.

When done, the result should be directly renderable with curl against JSONClip.

Notice what did not change: the manifest did not change, the output artifacts did not change, the Dropbox normalization requirement did not change, and the final render command did not change. That is a healthy sign. It means the real system contract is between your asset manifest and JSONClip, with the coding agent acting as the planner and file generator in the middle.

What the generated JSONClip movie should look like

Once the links are normalized and the scene order is decided, the agent’s main job is to produce a valid `movie.json`. This file should be boring too. It should not hide logic. It should show the scenes, overlays, audio tracks, effects, and captions clearly enough that a human can audit it quickly.

{
  "env": "prod",
  "movie": {
    "format": {
      "width": 1080,
      "height": 1920,
      "fps": 30,
      "background_color": "#000000"
    },
    "scenes": [
      {
        "type": "image",
        "src": "https://www.dropbox.com/scl/fi/a111/cover.jpg?rlkey=cover111&dl=1",
        "duration_ms": 2200,
        "transition_out": { "type": "white_strobe", "duration_ms": 220 }
      },
      {
        "type": "video",
        "src": "https://www.dropbox.com/scl/fi/v333/hero.mp4?rlkey=hero333&dl=1",
        "duration_ms": 4600,
        "transition_out": { "type": "blur", "duration_ms": 320 }
      },
      {
        "type": "image",
        "src": "https://www.dropbox.com/scl/fi/a222/detail.jpg?rlkey=detail222&dl=1",
        "duration_ms": 1800,
        "transition_out": { "type": "snap_back", "duration_ms": 240 }
      },
      {
        "type": "video",
        "src": "https://www.dropbox.com/scl/fi/v444/cutaway.mp4?rlkey=cut444&dl=1",
        "duration_ms": 3600
      }
    ],
    "overlays": [
      {
        "type": "text",
        "text": "Launch Faster With JSONClip",
        "from_ms": 120,
        "to_ms": 2400,
        "position_px": { "x": 540, "y": 220 },
        "width_px": 820,
        "style": {
          "font": "Avenir Next",
          "size_px": 92,
          "bold": true,
          "align": "center",
          "color": "#ffffff"
        },
        "stroke": { "color": "#000000", "width_px": 5 }
      },
      {
        "type": "image",
        "src": "https://www.dropbox.com/scl/fi/l888/logo.png?rlkey=logo888&dl=1",
        "from_ms": 9700,
        "to_ms": 12200,
        "position_px": { "x": 540, "y": 1460 },
        "width_px": 260,
        "opacity": 1
      },
      {
        "type": "text",
        "text": "See how automation works",
        "from_ms": 9800,
        "to_ms": 12200,
        "position_px": { "x": 540, "y": 1680 },
        "width_px": 720,
        "style": {
          "font": "Avenir Next",
          "size_px": 68,
          "bold": true,
          "align": "center",
          "color": "#ffffff"
        },
        "stroke": { "color": "#000000", "width_px": 4 }
      }
    ],
    "audio": [
      {
        "src": "https://www.dropbox.com/scl/fi/m555/voice.mp3?rlkey=voice555&dl=1",
        "role": "voiceover",
        "from_ms": 0,
        "to_ms": 12200
      },
      {
        "src": "https://www.dropbox.com/scl/fi/m666/music.mp3?rlkey=music666&dl=1",
        "role": "music",
        "from_ms": 0,
        "to_ms": 12200,
        "volume_db": -10,
        "duck_under_voice": true,
        "fade_out_ms": 500
      }
    ],
    "effects": [
      { "type": "zoom_in", "from_ms": 0, "to_ms": 1700, "settings": { "strength": 1.1 } },
      { "type": "warm_flash", "from_ms": 6400, "to_ms": 7400 },
      { "type": "fade_out", "from_ms": 11600, "to_ms": 12200 }
    ],
    "captions": {
      "src": "https://www.dropbox.com/scl/fi/s777/captions.srt?rlkey=sub777&dl=1",
      "format": "srt",
      "style": "bold_bottom"
    }
  }
}

This example does a few important things. It uses the cover still as a short hook, transitions into the hero clip, uses a detail still to reset attention, then ends on another moving clip with branded overlays. Voiceover carries the narrative. Music stays under the voiceover. Captions come from the user-supplied SRT. Nothing here is magical. That is the point. The automation value comes from consistency, not from novelty for its own sake.

Why JSONClip is the rendering layer you want here

Claude Code and Codex are not video renderers. They are planners, file writers, and command runners. JSONClip is the renderer. Keeping that boundary explicit improves reliability. The agent should decide scene order, prompt-friendly style decisions, and file output. JSONClip should render the result from a stable schema. That is much better than asking the agent to improvise ffmpeg filters or invent a desktop editor sequence on every run.

This division of labor matters for maintainability. If the agent owns everything, you get one-off cleverness. If the agent owns planning and JSONClip owns rendering, you get a workflow you can inspect, version, and troubleshoot.

How to run the render

curl -sS -X POST 'https://api.jsonclip.com/render?sync=1'   -H 'Content-Type: application/json'   -H 'X-API-Key: YOUR_API_KEY'   --data @build/movie.json

{
  "ok": true,
  "job_id": "01JCLAUDECODEXDROPBOX",
  "movie_url": "https://renderer.jsonclip.com/jsonclip/movies/example.mp4",
  "duration_ms": 12200,
  "credits_used": 61
}

You can keep this even more disciplined by having the agent write `build/render.sh` exactly once and then treating that script as the stable execution surface. That means future operators do not need to copy giant curl blocks manually. They just regenerate the build artifacts and run the script.

mkdir -p assets build
cat > assets/user_assets.json <<'JSON'
... user asset manifest goes here ...
JSON

# Claude Code
claude -p "$(cat prompts/claude_prompt.txt)"

# or Codex
codex exec "$(cat prompts/codex_prompt.txt)"

bash build/render.sh

What the agent should write besides the movie JSON

The movie JSON is not enough on its own. A good automation run should leave behind a small audit trail. That means at minimum a normalized asset manifest, the movie JSON, the render shell command, and one note file explaining scene order and editorial choices. Without those files, the run is technically reproducible only in theory. With them, another operator can inspect what happened in two minutes.

# Build notes

- Opening still image is used as the fastest hook because user assets often arrive with one strong poster frame before moving footage is approved.
- The first video clip carries the core promise and the second clip prevents the render from feeling like a static slideshow.
- Voiceover is primary narrative structure. Music is intentionally ducked.
- Captions come from the user SRT rather than generated inline so the workflow stays friendly to reviewed subtitle files.
- The CTA ending uses the provided logo instead of inventing a branded ending card.

- All Dropbox links rewritten to dl=1
- No local file paths left in movie.json
- Voiceover and music both present when supplied
- Captions linked from the reviewed subtitle file
- Scene order matches the campaign brief
- CTA text and logo appear at the ending
- No invented media beyond the provided user assets

A production-ready operating model

The easiest mistake is to think this workflow is just “ask Claude Code to make a video” or “ask Codex to make a video.” That is not the system. The real system is a sequence of constrained steps: user assets manifest, Dropbox normalization, planned scene mapping, generated render JSON, validation, and final render. Each step should leave an artifact behind. That is what makes the flow auditable and production-friendly.

1. Receive or update `assets/user_assets.json` from the user or upstream workflow.
2. Run the coding agent with a prompt that requires normalized URLs and explicit build outputs.
3. Inspect `build/normalized_assets.json` and verify all Dropbox links are in direct-download form.
4. Inspect `build/movie.json` for obvious scene or brand mistakes.
5. Run `build/render.sh` against JSONClip.
6. Store the resulting `movie_url` back in the system that requested the video.

That sequence is fast enough for manual operator use and structured enough for later orchestration through a job queue, a webhook runner, or another automation layer. It is also easy to debug because each stage has a visible file output.

Where people get this wrong

• They give the agent only raw Dropbox URLs and no manifest describing asset roles.
• They forget to convert `dl=0` to `dl=1` and assume a preview link is a render-safe media URL.
• They ask for “something cool” instead of defining required outputs and guardrails.
• They let the agent invent assets, music, captions, or logos that were not actually supplied.
• They skip the normalized manifest artifact, which makes later debugging painful.
• They ask the agent to own too much rendering logic instead of using JSONClip as the rendering contract.

All of those mistakes come from the same root problem: people treat the agent as a creative black box instead of a file-oriented automation layer. The fix is not to use less AI. The fix is to use the agent in the right role.

How to think about user assets specifically

User assets are messy by nature. One user uploads a polished product hero, another uploads a blurry screenshot, another uploads only voiceover and one still image. The agent should not hide that messiness. It should normalize it. That means mapping weak assets to lower-risk roles and stronger assets to primary roles.

That table looks obvious, but making the logic explicit helps the agent make better decisions and helps humans audit the output later. When a render looks wrong, you want to know whether the agent mapped the assets badly or whether the source assets were weak. Hidden reasoning makes that hard.

Claude Code versus Codex in practice

People often ask which agent is better for this workflow. The wrong answer is a tribal answer. The better answer is operational: the quality of the asset contract and prompt contract matters more than tiny differences in phrasing style. If both agents can read files, write files, run commands, and follow the output contract, the workflow is viable.

That is also why this workflow is strategically strong. It avoids locking your business logic inside one model-specific ritual. The workflow belongs to your files, your prompts, and your render contract.

Troubleshooting guide

What to monitor once this is running repeatedly

The first thing to monitor is malformed asset manifests. The second is bad Dropbox link hygiene. The third is asset quality drift. Teams often blame the agent for outputs that are actually caused by weak user inputs or inconsistent manifests. If you want stable automation, monitor the contract, not only the render time.

• How many runs fail because a Dropbox link is still in preview mode.
• How many runs need human correction because asset roles were ambiguous in the manifest.
• How often the agent introduces unnecessary effects or transitions.
• Average render startup time when assets are hosted in Dropbox.
• How often subtitle files arrive late or malformed compared with other asset types.

That data tells you where to harden the system next. Sometimes the answer is a stricter manifest schema. Sometimes it is a preflight validator. Sometimes it is moving hot assets from Dropbox to a CDN later. But you should only make that call after you observe the failure pattern.

Why this beats manual editing for recurring jobs

A manual editor can absolutely build a great one-off video from the same asset pack. That is not the question. The real question is what happens when the same pattern repeats across dozens or hundreds of jobs. That is where Claude Code or Codex plus JSONClip becomes materially better. The scene logic can be reused. The manifest structure can be reused. The render command can be reused. The human only changes the inputs and constraints.

That does not mean the human disappears. It means the human stops spending time on mechanical sequencing and starts spending time on prompt quality, asset quality, and system quality. That is the right tradeoff in automation work.

Conclusion

Fully automating video creation with Claude Code or Codex is not mainly about finding the smartest prompt. It is about designing a workflow that starts with structured user assets, normalizes hosted URLs correctly, writes explicit render artifacts, and uses a deterministic rendering API. Dropbox, a coding agent, and JSONClip fit together well because each one solves a different part of that chain.

Dropbox hosts the incoming user assets. Claude Code or Codex turns those assets and the brief into concrete files. JSONClip renders the output from a stable movie schema. When you respect those boundaries, the result is not an AI gimmick. It is a credible automated video pipeline.

The practical advice is simple: insist on an asset manifest, convert every Dropbox link to `dl=1`, require the agent to write normalized artifacts, keep the final render in JSONClip, and audit the result like an engineer instead of admiring it like a magic trick. That is how the workflow scales.

FAQ

Can Claude Code and Codex both work with the same Dropbox asset manifest? Yes. That is the recommended pattern. Keep one asset contract and let the prompts differ only where necessary.

Why not let the agent upload local files somewhere else first? You can, but if the user assets already live in Dropbox, using the shared links directly is usually faster operationally.

Why does `dl=1` matter so much? Because JSONClip needs a machine-fetchable file URL, not a human-oriented preview page.

Should I store captions inline or as an SRT file? If the subtitles come from a reviewed external file, using the SRT directly is usually cleaner and easier to audit.

Do I need separate JSONClip templates for every agent? No. You want agent-agnostic render contracts as much as possible.

What should the agent never invent? Assets, brand claims, legal disclaimers, or CTAs that are not supported by the brief or manifest.

Methodology and sources

This article is based on the live JSONClip hosted-media render model, existing JSONClip API patterns for remote images, video, audio, subtitles, and Dropbox-hosted assets, plus official product documentation for Claude Code, Codex, and Dropbox shared-link download behavior current as of April 6, 2026.

• Anthropic: Claude Code overview
• OpenAI: Codex use cases
• Dropbox Help: How to force a shared link to download or render
• Dropbox Help: How to set shared link permissions
• JSONClip docs
• Dropbox hosted-assets guide for JSONClip
• JSONClip API hosted-media tutorial