Work Across Every App

The project connection wires Claude Code to one app. But real work often spans several: the change to your storefront also touches the inventory app it calls, and you want to see both running side by side while you build. Your org-level AI connection makes that a single session. With one connection authorized, Claude can fetch a clone URL for any app in your org and assemble the environment to run it locally — so you pull down the two or three apps a piece of work touches, open them in one workspace, and let Claude build across all of them at once.

​

Why this is different from the per-app flow

The per-app guides get you into one repo, and Run Your App Locally boots it with stardeck env pull (which needs an Admin API key and the CLI). The org connection folds both into MCP tools Claude calls for you: The trade-off: the org tools that touch code (get_repo_access, get_project_dev_env) require a role with repo access on a read & write connection. See Tools & Permissions.

​

Before you begin

• An org AI connection authorized in Claude Code — see Connect Your AI Tool. The server URL is https://www.stardeck.ai/api/mcp.
• The connection bound to a role with repo access, authorized at the read & write level. Without it, the code tools don’t appear.
• Git and Claude Code on your machine, and Node for running the apps.

​

Pull an app

Just ask, in plain language, in your working directory:

Clone our storefront app here so we can work on it.

Under the hood Claude calls get_repo_access with the app’s name, gets back a clone URL with a short-lived token embedded, and runs git clone. You end up with an ordinary local checkout on the app’s default branch. Repeat for each app the work touches. Open them together in one Claude Code workspace (a parent folder holding each checkout works well) and Claude can read and edit across all of them in the same session.

​

Run an app locally

To boot one of the checkouts:

Set up the storefront to run locally and start it.

Claude calls get_project_dev_env for that app and gets the variables it needs to run — its deployment identity and secret, the sandbox database URL, the control-plane URL (in both the VITE_/NEXT_PUBLIC_ forms client code reads), its data-store connections, and its custom env vars. Claude writes them to .env.local, installs dependencies, and runs the dev server. The result: the apps a change spans, all checked out and running against their live sandbox data, with Claude editing across them in one conversation — the same loop you’d build by hand pulling repos locally, without the per-repo setup.

​

Shipping changes

The git rules are the same as the single-app flow, and worth re-reading: Stardeck agents commit straight to main, and the sandbox doesn’t auto-pull your pushes — you load a pushed commit into the sandbox from the dashboard’s git history tab. See Working alongside the Stardeck agent for the branch-and-merge workflow, and apply it per repo.

​

Seeing the whole system

Once you’re working across apps, the System Map in your dashboard shows how they connect — which app calls which, what reads which data store — so you can see the shape of what you’re changing before you change it.

​

Next steps