> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stardeck.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Work Across Every App
> Clone and run any app in your org from a single Claude Code session — no per-repo setup, no API keys, just your org connection.
The [project connection](/local-claude-code/connect) 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](/ai-integrations/overview) 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.
This builds on the org connection from [AI Integrations](/ai-integrations/overview), not the per-project `.mcp.json`. One org connection reaches every app; you don't add a connection per repo.
## Why this is different from the per-app flow
The [per-app guides](/local-claude-code/connect) get you into one repo, and [Run Your App Locally](/local-claude-code/running-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:
| | Per-app flow | Org connection |
| ------------------ | ----------------------------------- | ----------------------------------- |
| Reaches | One app (its `.mcp.json`) | Every app in the org |
| Get the repo | You clone it yourself | `get_repo_access` mints a clone URL |
| Get the env to run | `stardeck env pull` + Admin API key | `get_project_dev_env` returns it |
| Setup per app | One `.mcp.json` per repo | None — one connection |
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](/ai-integrations/tools#working-on-app-code).
## Before you begin
* An **org AI connection** authorized in Claude Code — see [Connect Your AI Tool](/ai-integrations/connect). 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.
Each app must have **agent development enabled** for these tools to work on it. It's on by default for every app — a per-app safeguard for apps that should never be pulled locally. A dashboard control to turn it off per app is coming; today it's on for every app.
## 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.
The token in the clone URL is **short-lived** (about an hour). It's enough to clone; for a long session, the token in your git remote will expire. If a later `git push`/`pull` fails to authenticate, ask Claude for repo access again and update the remote — or use your own [GitHub access](/github-access) for the git remote and keep the minted token just for the initial clone.
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 environment is the app's **sandbox** environment — the same data store, secrets, and storage your cloud sandbox uses. Reads and writes hit shared sandbox data, not production. `.env.local` holds real decrypted secrets; it's git-ignored — never commit it.
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](/local-claude-code/connect#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](/cross-app/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
Authorize the org connection Claude uses to reach every app
The repo-access and dev-environment tools, and the role that unlocks them
See how the apps you're working on connect
The one-app flow with the CLI and an Admin API key