Chataway Developers
Publishing

Sharing via GitHub

Share local apps outside the store — push to GitHub (private by default), install links pinned to a commit, what the install screen shows, the agent check, updates with a diff, revocation, and Open source to fork an app.

The store is for cloud apps that strangers install. Everything else — the tool you built for yourself, your team's internal app, an MCP server you found on GitHub — is shared through GitHub (or npm). Anyone can install from there; Chataway labels it Unverified, pins it to an exact commit, runs its code isolated, and lets the user's own agent read it first.

#Share your app

In an app project, open Share ▾ in the App strip:

  1. Push to GitHub — commits pending changes, creates the repository with the GitHub CLI (gh) if there's no remote yet, pushes, and tags v<version>. New repositories are private; Push to GitHub (public)… asks first, because anyone can then read the code. Without gh, Chataway shows the commands to run.

  2. Copy install link — available once the commit is on GitHub:

    https://chataway.co/install?repo=acme/sales-poster&ref=3f9a2c1e…

    The link is pinned to that commit. Whoever opens it gets a small page with Open in my Chataway (their own Chataway, once they're signed in on chataway.co — the phone works too), Open in Chataway on this Mac, and the text to paste into Install from GitHub by hand.

A private repository only installs on Macs whose GitHub sign-in can read it — Chataway uses gh auth token (or GITHUB_TOKEN) when one is there. To share widely, make the repository public.

Not using app projects? Any repository works, as long as Chataway can find an app in it — below.

#Install from GitHub

Apps → Store → Install from GitHub accepts:

You pasteInstalls
owner/repo · github.com/owner/repo · git@github.com:owner/repoThe default branch's newest commit
owner/repo@v1.2.0 · a /tree/<ref> or /commit/<sha> URLThat tag, branch or commit
https://github.com/owner/repo/tree/main/apps/posterOne folder of a monorepo
npm:@acme/mcp-server · npm:pkg@1.4.0 · an npmjs.com URLThat npm package version
An https MCP server URLA connector

Chataway resolves the input to one commit (or one npm version) and installs exactly that — never a moving branch. It then looks for:

  • a Chataway app — plugin.json at the root, in the folder you named, or in a single subfolder;
  • a Claude Code plugin — .claude-plugin/plugin.json: its skills, commands (as skills), hooks and stdio MCP servers;
  • a Node MCP server — a server.json, an MCP SDK dependency or the mcp keyword. Chataway generates a manifest for it and lists every tool it offers. (Python servers aren't supported yet.)

#The install screen

🎨 Sticker Maker                                    Unverified · Isolated
github.com/acme/sticker-maker · commit 3f9a2c1 · ★ 214 · MIT

Its code runs in its own process: it can read only its own folder and
storage and reach only api.acme.dev. Chataway hasn't reviewed it.

It says it will:
  · Receive files you or the agent hand it
  · Reach the internet                                        (network)

Setup:  npm install --ignore-scripts --no-audit --no-fund --omit=dev

[ Check with my agent ]                                       [ Install ]
  • Trust line — what Chataway enforces for this code, in words. An app with exec says it has full access to this Mac, isolated or not (why).
  • Permissions — your permissions sentences and grants, in the same wording users see everywhere.
  • Setup commands — listed up front and run only on Install, without install scripts and without secrets in the environment.
  • Check with my agent — optional. The user's own agent (the background model of their default provider) reads the code and reports where it connects, which files it touches, what programs it starts, whether it reaches for the screen or input, obfuscated or minified code, install scripts, and whether it matches what it claims to do. The report is advisory and saved with the install.
  • Install — the app lands in Apps, switched off in every project until the user turns it on (with the normal consent).

Downloads are capped at 50 MB (150 MB unpacked). Archives with paths that escape the folder, hard links or devices are refused; symlinks are never created.

#Updates

Chataway follows the ref the app was installed from — a branch's head, the newest version tag, or npm's latest — and checks when the user opens the app's page and once a day. An update is never applied silently:

  • The app page shows Update available; Review opens a screen with the diff (files and lines) and anything newly asked for. Check the diff with my agent reviews only what changed.
  • Wider access — a new grant, host, account, hook, MCP command or required app — needs the user's OK again in every project where the app is on.

Tag releases (v1.2.0) so users follow your releases rather than every commit.

#Safety nets

  • Revocation. Chataway's signed revocation list can name a repository and a range of commits. Matching installs are switched off everywhere, can't be turned on, and the user is told why.
  • Uninstall asks whether to keep the app's data (files, settings) in case it's installed again.
  • Open source. Any installed GitHub app can be turned into an app project of your own: Open source copies it into ~/Chataway/Apps/, commits it, and links your copy under the same id, wherever the original was on. From then on it's yours (DEV) — edit it with your agent, and Share pushes your fork.

#Make a repository installable

  • Put plugin.json at the root (or in one folder and share the /tree/<ref>/<folder> URL). Use "pluginApiVersion": 3 and a server entry for a local app.
  • Keep every file the server imports inside that folder — Chataway bundles the server for isolation, and an import from outside fails the build. Native addons can't be used.
  • await every ctx call (why), and test with Run isolated on before you push.
  • Declare every host in network.domains, with the network grant — undeclared hosts are blocked.
  • Explain every grant in permissions; it's the first thing people read.
  • If your app needs other apps, list them in requires. A GitHub app may require another GitHub app — { "id": "com.acme.helper", "github": "acme/helper", "reason": "…" } (its plugin.json id plus where to get it); that one gets its own install screen first — never a silent install.
  • Write a README for humans, and a CHANGELOG.md.