Export and clone an App
Download a Kortecx App as one portable file, clone it under a new name, and see what travels and what never does.
An App is work you have saved in Kortecx and can run again — see Apps. Sharing one means writing it to a single file and handing that file over: attach it to an email, drop it in a shared folder, commit it to a repository.
The file is called a bundle: a .zip archive named after the App's handle.
Two things are worth knowing before you send one.
A bundle carries no authority. No secret, no password, no API key, and no permission travels inside it. When someone installs a copy of your App, it runs under their account with their permissions — never yours.
A bundle is not signed. There is nothing in the file that proves who made it. Read what is inside before you run it.
Why exporting the App alone is not enough
An App is two things: its definition — the steps, the settings, the budgets — and the text it works from, its prompts, rules, context and skill instructions. Exporting the definition on its own gives you a file that describes an App without carrying what the App says. That round-trips on your own machine, where the text is already present. On someone else's it describes an App they cannot run.
A bundle fixes part of that. It is one archive: the App's definition (app.json) plus every file of the App's project tree, packed into one file. Text the App names only by pointer is not packed.
Export an App
Write the bundle
Open the App and use the download control in its header. The console is where you read an App before you send one anywhere — its files, its structure, and what it asks for. The download holds the definition and the project files; text the App names only by pointer is not packed. Where the console cannot write one the control says so instead of failing after you press it.
Datasets do not travel
A bundle carries no dataset payloads. An automation App that names a dataset is refused when it runs, whoever runs it.
See Datasets.
Check the files for secrets before you send them
The project files travel verbatim, and the download does not scan them for credentials. You are the one responsible for what is in your App's files: read them before you send the download anywhere.
What travels, and what does not
Connections and secrets never travel
An App that reaches out to an external service carries only the name of the credential it wants — never the credential. There is no field in the format that can hold one.
Today an App that names a connection is refused when it runs, whoever runs it, with the code app_missing_integration: a credential name alone is not enough to run it. See Connections.
Travels in the bundle:
- the App's definition — its blueprint, steering settings, and budgets
- every file of the App's project tree
Never travels:
- secrets, API keys, tokens, passwords — any credential value
- registered connections (only the credential name the App asks for)
- your grants, permissions, or policy
- run history, results, and cost records — the format has no field for any of them
- any file on your host filesystem
Give someone a copy they can run
To hand someone a copy they can run, publish the App to the marketplace; an install copies it into their own account.
A copy can never widen what you are allowed to do
This is the guarantee worth stating on its own.
An App carries a request for capability — the tools it wants, the connections it wants, the model it wants. The runtime grants only the overlap between that request and what you are already permitted to do. A request is never authority.
So a copy of someone else's App:
- runs under your account and your permissions
- resolves every tool grant against your policy, at run time, inside the runtime rather than in the App
- is refused at run if it names a connection
- fails closed if it names a model this instance does not serve, rather than quietly running on a different one
Nothing in the file can change any of that. There is no field for a permission, no field for a grant, no field for a secret. Sharing an App is sharing a plan, never a key. See what you can rely on.
Sharing between people, one file at a time
You hand someone a file to read; it shows them the App, and grants them nothing. There is no registry and no link to send, and nothing in the file establishes who wrote it — so sharing works between people who already trust each other, and gives you nothing extra when they do not.
Clone an App locally
To make a copy of one of your own Apps under a new name — a safe place to experiment, or a starting point for a variant — clone it. Nothing is exported and nothing transfers, because the content is already where the runtime can reach it.
If an App already exists at the new name, the clone stops and asks you to pick another.
Lineage is a hint, not a signature
A clone records where it came from — a note naming the App it was copied out of. It is useful for answering "where did this copy come from" when you already trust the source.
It is not a signature. Nothing binds that note to a person. Kortecx has no signing, no publisher identity, and no notion of a trusted source, so provenance across parties you do not already trust is unavailable — treat a bundle from a stranger exactly as you would treat a script from a stranger: read it first.
The file itself
A bundle is a plain .zip archive. Unpack it and you can read every file in an editor before you run anything — the file itself is the evidence.
Inside it are app.json, the App's definition, and the App's project files under tree/. There is nothing else in there; an App with no project files ships app.json alone.