--- title: "Is it safe to let a coding agent record your app? | tday" description: "What can go wrong when an AI coding agent records a demo of your app, what tday prevents on its own, and the two things you set up yourself." url: https://tday.com/blog/is-it-safe-to-let-a-coding-agent-record-your-app markdown: https://tday.com/blog/is-it-safe-to-let-a-coding-agent-record-your-app.md last_updated: 2026-11-10 --- # Is it safe to let an AI coding agent record a demo of your app? What can go wrong when an AI coding agent records a demo of your app, what tday prevents on its own, and the two things you set up yourself. By the tday team Published November 10, 2026 7 min read ## The short answer Yes, when the demo runs on its own copy of your app with throwaway data and test keys, and nothing uploads until it passes a secret scan. Your agent starts a separate demo instance. In web and Electron demos tday blocks outbound writes from the app's window and swaps your name and email for a demo persona, and it checks every take on your machine before upload. Two things are yours to set up: a disposable database for the demo and test keys for your app's server. ## Key takeaways - The risks are concrete: a demo could change a real database, send a real email or charge a real card through your server, or show a secret on screen. - tday records against a second instance of your app on a free port. Your dev server is never restarted or reused, and recording changes no code. - Before anything starts, demo\_check reads your env, seed command, ports and tools, and your agent waits for your OK when anything is shared or live. - The upload is the take, a poster frame and a manifest. Source code, .env files, cookies and network traffic never leave your machine. - The window guard does not cover your app's server: give the demo test keys, and a database made for it. ![The first-demo screen zoomed in on its stages, with the checks No new branch, Its own data, Test keys only and Checked before it uploads.](https://tday.com/blog/first-demo-safety-check.webp) Letting a coding agent drive your app on camera sounds risky, and it should. The agent runs real commands with your shell and your env files, and the app it drives talks to real services. But "is it safe" is too vague to answer. The useful question is what, exactly, could go wrong. There are four things. tday handles most of them for you, and two parts are yours. ## What can go wrong when an agent records your app In rough order of how much each would hurt: 1. **Real data changes.** A seed or a `migrate reset` pointed at the wrong `DATABASE_URL` replaces that database's data. 2. **Something real is sent.** A click sends an email, charges a card or posts in Slack, because the app's server holds live keys. 3. **Something private is filmed.** A real customer's name from a copy of production, your own email in the corner, or a token typed on camera. 4. **More than the video leaves your machine.** Source code, env values or network traffic. ## What tday does on its own | Protection | What it does | | --- | --- | | A separate demo instance | Your agent starts a second copy of your app on a free port. Your own dev server is never restarted or reused. | | A data check | `demo_start` refuses a database that is not on your machine unless you say yes. A take that changed your existing local data without your OK is not uploaded. | | The window guard | While a web or Electron demo records, requests from the app's window that would change something off your machine are blocked and counted. Reads, fonts and images still load. | | A demo persona | Your git name, email, user name and machine name are swapped for a made-up persona on screen. | | A secret scan | Sign-in happens off camera, and anything that looks like a secret, on screen or in a narrated line, blocks the upload. | | A clean repo | `git status` is compared at the start and the end, and every temp file is removed. | | The review | A local page shows the take, every line and every check. Only a take that passes them uploads. | Secrets your agent types are written as `$env:NAME`: the value is read from your environment at the moment of typing and never recorded, and a step that would type one on camera is refused. ## The safety check runs before anything starts Before your agent starts a demo instance or touches a database, it runs `demo_check`. The check only reads. Each row comes back `ok`, `check` or `stop`: | Row | What it looks at | | --- | --- | | Repo | Your branch, and uncommitted files that will show in the demo | | Data | Each database URL or host setting, whether it is on your machine, and your seed command | | Queues and caches | Hosted ones the demo would share with your real app | | Server keys | Live keys, and services your server could send, message or charge through | | Ports | Your dev server's port, left alone, and a free one for the demo | | Tools | What a recording of your kind of app needs | Your agent then tells you what it will use, and waits for your OK when anything is shared or live. tday is sent each row's result, never what it found. ## What leaves your machine Once a take passes its review, the tool uploads three things: - **The take**: the app's window only, with nothing recorded between narrated lines. - **A poster frame.** - **A manifest**: each narrated line, each step your agent took (in a few words, with the control's name and what it typed), where on screen it happened, and the safety results, such as how many outbound requests were blocked. Signed in with your own tday login, the tool also sends your repo's owner and name, such as `acme/web`, so tday can find the brand it belongs to. A prompt's token already belongs to one brand, so it sends no repo name. Your source code, `.env` files, cookies and network traffic never do. While recording, each narrated line is sent to tday for notes on its wording and is not stored. A line that looks like it holds a secret is not sent at all. The note your agent may save on how it started your app (commands and variable names, never values) stays in your repo's `.tday` folder. Review a change to it as you would a change to your build scripts, because agents run the commands in it. ## The two things you set up yourself The window guard watches the app's window, in web and Electron demos. Two things sit outside it. **Your app's server.** The demo's backend runs with the keys it is started with. If they are live, a click can send a real email or charge a real card, and the guard never sees it, because the request comes from your server. Use test keys for payments (such as Stripe's `sk_test_`), a sandbox or log mode for email, no chat webhooks, and a separate project for a hosted backend like Supabase, Firebase or Convex. **The demo's data.** Your agent takes the first of these your repo supports: its own throwaway-database tooling (a Neon, PlanetScale or Supabase branch, a docker compose service), a temporary SQLite or PGlite file, or a temporary database on your local Postgres or MySQL. Keep it away from your shared dev database, staging, production or a copy of production, which holds real people's names and live integration tokens. The guard also has edges of its own. An Electron app's main process can use the network outside its window, and a Mac app demo has no window guard, so your agent asks you before it starts either. A few lines in your repo's agent instructions (`CLAUDE.md`, `AGENTS.md`, Cursor rules) settle both for good: ```markdown ## Demo recordings (tday) - Demo instances use their own database: createdb myapp_demo_, then run the migrations and `npm run seed` with DATABASE_URL pointed at it. Never migrate or seed the DATABASE_URL in .env. - Start the demo instance with .env.demo (Stripe test keys, EMAIL_MODE=log, no Slack webhook). - Sign in as demo@example.com. The password is in $env:DEMO_PASSWORD. ``` Watch [Keep demos safe](https://tday.com/tevespq9) (1:43), a demo of tday recorded by a coding agent with tday. ## Staying in control during a take - **Watch it.** Ask your agent to record with the window showing, and keep its approval prompts on so you see each command before it runs. - **Stop it.** Stop your agent at any time. Nothing uploads before a clean review, so a demo stopped mid-recording uploads no video. Then ask it to run `demo_finish` to clean up. - **Take it back.** Delete an upload you did not mean in tday. It moves to Trash, and its share link and embeds stop playing at once. Phone and Mac apps are the exception to on-screen swapping. Text in an iPhone or Android app, or a Mac app's own window, cannot be swapped, so your agent signs in as a demo user with demo data instead. A Mac app demo also films your real screen, so your agent asks you to close what is private and turn on Do Not Disturb first. For the recording flow itself, see [how to record a demo with your coding agent](https://tday.com/blog/record-a-product-demo-with-your-coding-agent). Watch [Stay in control of every demo](https://tday.com/de3r865w) (1:15), a demo of tday recorded by a coding agent with tday. ## Frequently asked questions ### Can a coding agent recording a demo change my production database? It is set up not to. The agent gives the demo instance its own throwaway database and runs your seed in it, demo\_start refuses a database that is not on your machine unless you say yes, and a take that changed your local data without your OK is not uploaded. Check that the DATABASE\_URL in your .env is not a shared, staging or production database. ### Could a demo send a real email or charge a real card? Only if your app's server is started with live keys. In a web or Electron demo, the window guard blocks requests from the app's window that would change something off your machine, but your server sends with whatever keys it has. Use test keys, a sandbox or log mode for demos. ### Does tday upload my source code? No. For a demo, the upload is the take (the app's window), a poster frame and a manifest of the narration, steps and checks. Source code, .env files, cookies and network traffic never leave your machine. ### Will my name or email appear in the demo video? Not in a web, Electron or terminal demo: your git name, email, user name and machine name are swapped for a demo persona on screen. Phone and Mac app text cannot be swapped, so the agent signs in as a demo user instead, and the review flags your name or email if it can still be read. ### Can I stop the agent halfway through a recording? Yes, at any time. Nothing uploads before a clean review and its confirmation code, so a stopped take uploads no video. Ask the agent to run demo\_finish to close the recording and clean up. ## Sources 1. [Keep demos safe](https://docs.tday.com/demo-safety), tday docs 2. [What leaves your machine](https://docs.tday.com/capture-privacy), tday docs 3. [Demo FAQ](https://docs.tday.com/faq), tday docs 4. [Security](https://tday.com/security), tday ## Have your coding agent record your first demo One prompt in Claude Code, Cursor or Codex records a narrated demo of your app. tday voices, styles and renders it, ready for your docs. Free includes 5 saved demos. [Make your first demo](https://docs.tday.com/first-demo) [See pricing](https://tday.com/pricing) ## Keep reading - ![The title card of tday's Make your first demo video: a laptop showing tday's docs setup screen.](https://tday.com/landing/next/hero-poster.webp) Comparisons November 10, 2026 10 min read ### [The best demo video tools for developer-led startups in 2026, compared](https://tday.com/blog/best-demo-video-tools-for-developer-led-startups) 14 demo tools checked against their own sites on November 10, 2026: what each one makes, its free plan, its starting price, and how it keeps demos current. - ![tday's Record a demo dialog on the Demos page: Copy prompt, buttons that open Claude Code, Cursor, Codex and VS Code Copilot, and what happens before the agent records.](https://tday.com/blog/record-a-demo-dialog.webp) Guides November 10, 2026 7 min read ### [How to record a product demo video with Claude Code, Cursor or Codex](https://tday.com/blog/record-a-product-demo-with-your-coding-agent) A step-by-step guide to having your coding agent record a narrated demo of your app with tday's MCP server: the setup, the take, the checks and the edit. - ![tday's Demos from docs page: 25 sections ready to record across 13 pages of tday's own docs, with each page's sections listed.](https://tday.com/blog/docs-demos-from-docs.webp) Guides November 10, 2026 7 min read ### [How to add demo videos to your docs: Mintlify, GitBook, Docusaurus and more](https://tday.com/blog/add-demo-videos-to-your-docs) Which docs sections need a video, the embed code each docs platform takes (MDX, HTML, GitBook, a link), and four ways to keep demos in your docs current. --- ## For AI agents - Every page on tday.com is available as Markdown: add `.md` to its address (https://tday.com/index.md for the home page), or request it with `Accept: text/markdown`. - Site index: https://tday.com/llms.txt. Every page in one file: https://tday.com/llms-full.txt. - Docs: https://docs.tday.com (index for agents: https://docs.tday.com/llms.txt). - To record a narrated demo of an app from a coding agent, install tday's MCP server once with `curl -fsSL https://tday.com/install.sh | bash`, then ask the agent to record a tday demo.