Unsaved changes and drafts
How the web app keeps what you type in a form when you reload or navigate away, what the "Draft restored" notice means, and what a draft never includes.
Type into a form in the web app, then reload the page or wander off to another one, and your text is still there when you come back. CodeHerder keeps a draft of most forms as you fill them in, and tells you when it puts one back.
What happens to what you type
A moment after you stop typing, the form saves a draft. You don’t press anything.
- Reloading the page brings the draft back.
- Navigating away and returning in the same browser tab brings it back too.
- Saving or submitting the form deletes the draft.
- Closing or reloading the tab with unsaved changes makes your browser ask whether you really want to leave. The wording of that prompt belongs to your browser, and it appears only while the form has changes that aren’t saved yet.
An edit form works a little differently. It saves a draft only after you change something, so opening a task or setting and looking at it never leaves a draft behind. A draft identical to what’s already saved isn’t kept.
The “Draft restored” notice
When a form comes back with a draft in it, a notice appears at the top:
Draft restored from your last visit. Discard draft
Select Discard draft to throw the draft away. The form goes back to how it started: blank on a create form, or the saved values on an edit form. If the draft is what you wanted, ignore the notice and carry on.
Where your draft lives
A draft lives in the browser tab you typed in. That has some consequences:
- It doesn’t follow you to another tab, another browser, or another device.
- CodeHerder doesn’t receive it, so nobody else in your workspace can see it.
- Closing the tab loses it. That’s why your browser asks before letting you close a tab with unsaved changes.
- It expires after 24 hours. The box you use to send input to a live session is stricter: its draft lasts one hour.
Saving drafts is best effort. If your browser blocks site storage, as some private-browsing modes do, or its storage is full, the form still works but doesn’t keep a draft.
What is never saved
- Credentials. Sign-in, sign-up, and one-time-code screens never save a draft.
- Secret values. A variable or secret you type in, an API key you create, and the signing secret a webhook shows you once are all left out.
- Attached files. If a form holds an attachment, the text comes back but the file doesn’t. Attach it again. See Attachments.
Short one-field dialogs, such as inviting a member, adding a repository, or naming a new workspace, don’t keep drafts. Neither do inline edits that save as soon as you commit them.
Forms that keep drafts
The list changes as the app grows, so read it as examples rather than a complete inventory.
| Area | Forms |
|---|---|
| Tasks and comments | A new task, a task’s description edit, a new or edited comment, the blocker and reopen forms |
| Sessions and messages | A new session on a device, a new message or reply, the box for sending input to a live session |
| Wiki, skills, and workflows | The wiki page editor, the skill editor, the workflow and composition editors, the stage editor |
| Schedules and webhooks | A new or edited scheduled task, a new or edited webhook, an inbound webhook rule |
| Settings and team | Single sign-on connections, new agents, launch configs, teams, branding |
| Quality tools | Alert rules, prompt trials, surveys, and rejecting a workflow proposal |
Related guides
- Writing tasks an agent can build and Editing and cancelling tasks: the forms most people fill in first.
- Messages: drafts of new messages and replies.
- Sharing a view with a link: filters and layout live in the address, not in a draft.
Last updated
