Own the code, prove the exit

Code ownership sounds binary until the day you try to leave a tool. Then three separate questions appear:

• Ownership: who has the right to use, modify, sell, and deploy the work?
• Custody: which account and infrastructure hold the canonical files today?
• Portability: can another team reproduce the application without the original builder?

Mythos answers those questions differently. Under the current Terms, the user owns their prompts, project files, generated code, and Git history. The working repository is private but managed inside the Mythos GitHub organization. Connecting GitHub is optional; when connected, Mythos creates a new private repository in the selected user account or organization and synchronizes one selected active branch in both directions.

That distinction is deliberate, and it should stay visible in product copy. “You own the code” describes the contractual position between the user and Mythos; it does not certify that generated output is original or free of third-party rights. “The canonical repository is already in your GitHub” would be a false description of the current product.

Update — August 19, 2026: the outbound-only export described when this article was first published has been superseded. Mythos now creates a new private repository in the selected user account or organization and keeps one selected active branch in two-way sync; it does not attach an arbitrary existing repository.

The project's current tree seeds that selected branch. Builds, Reverts, and source-changing editor saves or deletes are projected outward. Signed GitHub push webhooks are recorded durably before a compatible external commit on the same branch is imported. Connection, outbound, and inbound work share a recovery path, so missed or interrupted work can retry without another Build.

There are two consequences worth stating plainly:

1. The connected repository starts with a clean snapshot. It does not receive the earlier internal commit history.
2. A source change can be safely delivered to the Mythos-managed repository before GitHub catches up, so the connected branch can temporarily lag while durable recovery retries.
3. Only one selected branch is active. Other branches remain untouched unless the user explicitly selects one.

The repository lives in the selected GitHub account or organization and is not deleted when the Mythos link is removed. Divergent selected-branch history becomes an explicit conflict: Mythos does not force-push, silently merge, or overwrite it. Treat the branch as synchronized until you disconnect it or select another, and compare its tree with the Mythos revision you intend to keep before an exit.

This is also why an exit test should compare files or tree contents rather than commit SHA. The managed and connected repositories can carry the same project state while having different commit identities.

Do this while the app is still cheap to move. Use a disposable machine or CI runner without production credentials.

1. Connect a GitHub account or organization you control and let Mythos create the new private repository.
2. Record the Mythos revision you are testing, then verify that the selected active branch contains the same files.
3. Prepare independent release changes on a separate unselected branch or fork, or use Disconnect in More → Git first. If the selected branch diverges, resolve the surfaced sync conflict; Mythos will not force-overwrite it.
4. Clone the independent repository into the clean environment. Inspect package.json and its lifecycle scripts before installing anything.
5. Supply only the documented environment variables, run the type and production-build commands, and repeat the install from a reviewed lockfile.
6. Deploy the output through the hosting mode you actually intend to use. Follow the Vite static deployment guide.
7. Exercise one real product flow against the deployment, including a direct-route refresh and a controlled failed request.
8. Restore the database backup into staging and validate the expected schema, representative row counts, authentication flow, and separately restored Storage objects.
9. Disconnect the Supabase integration when appropriate, then revoke server secrets or OAuth grants only after the replacement deployment is verified.

The companion release checklist covers the build and security checks in detail. The exit drill has a narrower purpose: prove that the source, configuration, hosting assumptions, and data can be reconstructed outside the builder.

Mythos uses a bring-your-own-backend model. If a project is connected to Supabase, its database, users, and stored files remain in the user's Supabase account. Mythos stores the connection material it needs in encrypted form while the service is connected; the generated frontend receives the project URL and public anon key.

Migration files may be present in Git, but the applied schema, table data, authentication behavior, Storage objects, and recovery settings still need their own evidence. Supabase documents the available database backup and restore options. Its database backups include Storage metadata, not the objects stored through the Storage API, so those objects need a separate export and restore path. Before production data matters, complete one staging restore drill.

An exit record for a stateful app should name:

• the source revision, connected repository, and selected active branch;
• the database project and latest verified backup;
• required public configuration and server-only secrets;
• the target host and deployment mode;
• the owner of credential revocation and the date it was completed.

Do not copy service-role keys into the repository to make the handoff easier. Transfer them through the target host's secret manager, then rotate or revoke the old access after the new deployment is verified.

Mythos projects are ordinary Vite + React applications with Tailwind and a package manifest. They do not need a proprietary Mythos client runtime in order to render. That makes the source readable to a normal TypeScript team and gives the project more than one hosting option.

It does not guarantee that every host is equivalent. A Vite single-page app needs correct static asset and route-rewrite behavior, so verify direct-route refreshes and asset paths on the chosen host.

Dependencies create another portability boundary. A repository without a reviewed lockfile does not yet prove a reproducible install. A new dependency version can change the graph, license obligations, or required Node runtime. After disconnecting GitHub or moving to an unselected independent branch, pin the supported Node major, review the dependency graph, commit a lockfile, and prove a second clean install.

Account deletion starts irreversible cleanup of live projects, internal repositories, published artifacts, and hosted previews. If external cleanup cannot finish in the request, deletion remains pending until the product confirms completion; no fixed completion time is promised. The Privacy Policy documents exceptions: some account records and encrypted backups can remain for up to 30 days, while financial and credit records can be retained for roughly seven years. A repository already created in the selected GitHub account or organization is outside that cleanup.

Before deletion, verify the connected repository and export the account JSON. Open the JSON and confirm that meta.complete is true, then verify both from outside the Mythos session.

The current exit has two gaps a user should plan around:

• the connected GitHub repository begins with a clean snapshot rather than the full internal history;
• selected-branch sync is asynchronous and can lag while durable recovery retries a recorded failure; divergence becomes a conflict and unresolved identity cases can still require operator recovery.

Both gaps affect the evidence needed before deleting the canonical managed copy. A complete handoff means another engineer can clone the connected source, configure it from written instructions, build it cleanly, deploy it to an appropriate host, restore its data, and continue without Mythos access. Run that test early. If it fails, the failure names the hidden environment value, unsupported server feature, stale sync, missing backup, or undocumented command while there is still time to fix it.