Let Claude Code (or any coding agent) record a demo of the feature it just built

Your coding agent just finished the feature. The tests pass and the pull request is open. Then someone asks for a short video for the changelog, the pull request or the sales team. So you open a screen recorder and click through the flow yourself, three times, because a toast covered the button on the first try and you typed the wrong email on the second.

There is a better split of work. The agent that built the feature should also record the demo, and a recording tool should turn what it does into something people want to watch.

#Why the agent that built the feature should demo it

The agent already has everything a demo needs:

• The flow. It knows which screens changed, in which order, and which button is new.
• The test data. It seeded the database or wrote the fixture, so it knows which account to sign in with.
• The proof. It knows what "done" looks like: the invoice in the list, the green badge, the saved file.
• Repeatability. It can run the same flow again next week, after the next change.

What an agent is bad at is being filmed. Point a plain screen recorder at an agent's session and you get a cursor that teleports, long pauses while the model thinks, and no idea where one step ends and the next begins. The fix is to separate acting from presenting: record what happened as a trace of meaningful actions, split the flow into scenes that end on a stable screen, check the outcome, and draw a smooth presentation pointer afterwards.

That is what DemoTake does. Your agent drives it over MCP, and the result is an editable take, not a flat video file.

#How to connect Claude Code, Codex or Cursor to DemoTake

DemoTake runs a local MCP server on your Mac, and it ships a small stdio bridge, demotake-mcp, that finds the endpoint and token on its own and launches DemoTake if it isn't running. For Claude Code, that is one line:

claude mcp add demotake -- /Applications/DemoTake.app/Contents/MacOS/demotake-mcp

Codex and Cursor point at the same bridge:

[mcp_servers.demotake]
command = "/Applications/DemoTake.app/Contents/MacOS/demotake-mcp"

{ "mcpServers": { "demotake": { "command": "/Applications/DemoTake.app/Contents/MacOS/demotake-mcp" } } }

In the app, Settings › Agents shows the endpoint and the last client that connected. Add to Codex writes the Codex entry for you and shows the change first, and Check Connection tests the server the way an agent connects. The full walkthrough is in Connect your agent.

#Teach it the workflow with the DemoTake skill

Tools alone don't tell an agent what a good demo looks like. The DemoTake skill is a single SKILL.md with the record, verify, edit and export workflow; drop it into your agent's skills folder. Agents without skills can call demotake_guide once, which returns the same workflow as plain text. See The DemoTake skill and the Agents page for more ways in.

#What the agent does, tool by tool

A typical run follows the same shape every time:

1. targets_list finds the window of the app it just built.
2. take_create plans the take: a name, a one-sentence goal, the target, the scenes and the outputs.
3. take_rehearse walks the flow with nothing recorded, which is where it finds the popup nobody remembered.
4. capture_start, then for each scene: take_start_scene, act, check the result with an assert_* tool, and take_checkpoint with a description of the stable state reached.
5. capture_stop, then an edit in plain words with edit_command, such as "make it 30 seconds and remove waits over 1s".
6. export_render with wait: true. Every export checks itself before it is marked ready.

Here is a real take_create call:

{
  "name": "Create invoice",
  "goal": "Show that a signed-in user can create an invoice and see it in the list.",
  "target": "window:1234",
  "scenes": [
    { "title": "Sign in", "intent": "Sign in with the demo account" },
    { "title": "Create invoice", "intent": "Fill in the new invoice form and save it" },
    { "title": "Invoice in list", "intent": "The new invoice appears at the top of the list" }
  ],
  "outputs": ["16:9", "9:16"]
}

If scene two goes wrong, the agent calls take_retry_scene, restores the starting state and records that scene again. Scenes one and three keep their footage. The complete list of tools is in the MCP tool reference.

#DemoTake Agent or DemoTake Studio: who clicks the buttons?

Both Mac editions run the same MCP server for planning, recording, assertions, editing and export. They differ in who operates your app.

With DemoTake Agent, actions go through Accessibility in the background by default. If an action truly needs the real mouse or keyboard, the tool says so. The agent can then retry with allow_foreground: true, and DemoTake's guide tells it to do that only when you aren't working. Allow foreground control in Settings › Capture allows it for every action, and is off by default. A banner shows while an agent has the mouse.

With DemoTake Studio, the agent clicks with its own tools and tells DemoTake what it did right after each meaningful step, so the pointer, zooms and edits land in the right place:

{
  "take_id": "take_01j…",
  "kind": "click",
  "label": "Click Save",
  "screen_point": { "x": 812, "y": 604 }
}

screen_point uses the same global screen points that computer-use tools use. If the agent knows the element, it can pass element instead. Editions and plans compares the two editions in full.

#Prompts that work

You don't need to name tools. Say what the viewer should see, what proves it worked, and which formats you want.

A few habits make the difference:

• Name the end state. "Ends on the invoice list with the new invoice at the top" gives the agent a checkpoint and an assertion.
• Keep scenes short. Three to six scenes, each one story beat. Short scenes are cheap to retake.
• Ask for a rehearsal on a flow with popups, permissions or slow screens.
• Say what to hide. "Hide the credentials" or "blur the customer emails" becomes a redaction, not a hope.

#Passwords, 2FA and other moments that need a person

Never paste a real password into a prompt. Use demo accounts, and have the agent mark secret fields as secure. DemoTake Agent detects secure fields on its own. Typed secrets are never logged, and they are masked in every render. Redaction covers the rest.

For a two-factor prompt, the simplest approach is to sign in before the take starts. If the prompt shows up mid-flow, the agent can pause the capture and ask you. Paused time is not recorded.

DemoTake also tells the agent when a person is needed. It emits a human_input_required event, for example when the recorded window stopped drawing, so an agent that listens with events_poll can stop and ask you instead of recording blank footage.

#Save the demo as demotake.json so it can run again

A take recorded once is useful. A take that can be replayed after every change is better. Ask the agent to call take_to_spec, and DemoTake converts the take into a demotake.json: steps with element queries, assertions, style and edit settings. Typed secrets become secret_env references, so the file is safe to commit.

Save this take as demotake.json in the repo root and commit it with the feature.

The spec replays best when DemoTake Agent performed the steps, because each step then carries a precise element query. From there, demotake test demotake.json runs the flow as an end-to-end test without video, and demotake run --only-changed re-records only the scenes whose screens changed. Automate demo videos in CI shows the whole setup, and Demo specs and CI documents the format.

#Try it on your next pull request

Download DemoTake, connect your agent with the line above, and ask it to record the feature it just finished.