Continue an imported Web-App from its source

Some publishers on the Kareenos marketplace open the source code of their web application's screens on GitHub. When you import such a project, you get your own working copy of the application, and you can keep building it yourself with Claude Code, starting from the publisher's source. One sentence connects the two: link this project to my imported project.

What you get when you import#

Importing a project creates a complete copy inside your account, under new identifiers: the project, the application with its own name and address, its routes and the jobs behind them, its sheets and its agents. The publisher's version of the screens is copied too, so your address shows a working application as soon as its routes are approved.

Nothing in your copy points back at the publisher. The one thing that still does is the source folder on GitHub: it was written against the publisher's account, so until it is linked, it would talk to their live application, not yours.

Before you start#

• You imported the project from the Marketplace. The import result names the source repository when the publisher declared one, and so does the application row in Settings, Apps & K-APIs.
• You have your own copy of the source: fork the repository on GitHub, then clone your fork.
• Claude Code is connected to your imported project in Tools mode. The quickest way is the Connect Claude Code button in the import result, which opens the connection form already filled in for your project. A connection created in the default Agents mode cannot build anything. See Connect Claude Code.

Link the folder#

Open your fork in Claude Code and say:

link this project to my imported project

Here is what happens, and what you will be asked:

1. Claude Code finds your application. It reads the identifiers it finds in the folder and asks Kareenos which of your applications they correspond to. Kareenos answers from the record your import kept, not from names, so a renamed project or application is still found. If you imported the same listing twice, you are asked once which copy to use.
2. Two small files are written, and nothing else: .kareenos/link.json (which project and application this folder belongs to) and public/kareenos.config.json (the settings the screens read during development). Both stay on your machine and are never committed, so your fork stays clean and later updates from the publisher merge without conflicts.
3. You get one summary of what is still open. An import deliberately leaves a few things for you to decide, and Claude Code lists them together:
   • routes that do not answer yet, because the jobs behind them wait for your approval;
   • configuration keys that are empty, because a publisher's secrets never travel with a listing: you provide your own values;
   • agents that are still drafts, and integrations that were switched off;
   • screens that call a route your copy does not have, which means the source is newer than the version you imported;
   • whether a newer version of the listing is available.
4. You approve once. Claude Code shows you the jobs your application's routes need and asks one yes or no. On yes they are approved together, in your name. Jobs that run on a schedule or react to events are not part of that question on purpose, because approving them makes them start running: each is explained and approved on its own.
5. Claude Code proves it. It calls one route of your application and shows you the answer.

From there you work as on any other application: describe the change, let Claude Code build the screen and its route together, review, and publish a new version. See Build a Kareenos Agentic Web-App.

When the publisher ships something new#

Two things can change on the publisher's side, and they reach you in two ways.

• The application's backend: routes, jobs, sheets. This arrives as a marketplace update. A banner appears on your imported project; open it, review the changes and choose what to take. An update never replaces the version of the screens you published yourself: the publisher's new version is added to your versions list, and you decide whether to switch to it.
• The screens' source code. This arrives through GitHub: bring the publisher's changes into your fork, let Claude Code build, and publish.

After either one, say link again. New routes usually come with jobs that wait for your approval, and the summary tells you exactly which.

If something goes wrong#

If you are the publisher#

You can make your own application's source ready for others in one step: open its folder in Claude Code and say prepare this project for open source. Claude Code removes your account's identifiers from the files you publish, adds the small files that let anyone link a fork, and checks that nothing private is left. Then enter the repository address on the application (Settings, Apps & K-APIs, edit the application, App source repo) and publish a new revision of your listing: everyone who imports it is shown where the source lives and what to say.

Keep the two GitHub features apart. App source repo is the repository of your screens' source code. Export to GitHub on a listing publishes the importable package instead, and it replaces the whole content of its repository every time, so it must be a different repository. Kareenos refuses the export when you point it at a source repository by mistake.