FAQ
Short answers to the questions developers ask most about building Chataway apps.
#Platform
#Can my app run code on the user's Mac?
A store app can't: only your panel's JavaScript runs on the Mac, in a sandboxed iframe, and everything else runs on your servers behind your MCP endpoint. For media work on the Mac (resize, convert, trim…), use host services.
A local app can — its server.ts runs inside Chataway. Local apps don't go to the store; you share them on GitHub, where they install as Unverified and run isolated. See Local apps for when to choose which.
#Do I have to use the terminal?
No. Apps → + New app creates an app project, and your agent builds, reloads and tests the app in it — and publishes a cloud app to the store from the App strip. See Build in Chataway. The CLI is there if you prefer your own editor or CI.
#The service I want already has an MCP server. Do I need an app?
Often not. If it supports MCP sign-in (Canva, Notion, Linear, Sentry, Stripe…), users add it as a connector by URL. Build an app only for what the connector can't do, and have it use the connector's tools rather than the raw API.
#Which languages can I write my server in?
Any language with an MCP server library that speaks Streamable HTTP — TypeScript, Python, Go, Rust, C#, Java, Kotlin… @chataway/apps/server is a convenience for Node; the wire format is small.
#Can I use an existing MCP server?
Yes, if it's reachable over HTTPS with Streamable HTTP. Declare the tools you want Chataway to offer in plugin.json (with good descriptions), add confirm to tools with side effects, and you have an app. Tools you don't declare are ignored.
#Does my app work with Claude Code, Codex, Cursor…?
Yes. Every provider in Chataway that supports tools gets your tools (OpenCode not yet). Chataway's own chat shows your cards inline; the others show them in the pending-asks strip above the composer. See Providers.
#Do my app's instructions reach Codex and Cursor too?
Yes — prompts, per-turn context and skills reach every provider, each through its own channel, within a shared 6,000-character budget. Write them provider-neutral: name your own tools, never Claude-only ones, and give a fallback. See Instructions for every agent.
#Does my app work on the phone?
Your tools run wherever the chat runs, so yes. The phone app shows your panel full-screen and your cards like on the desktop — design for narrow screens.
#Users and accounts
#How do I know which user is calling?
Through your own account system: declare an account, and each call carries that user's OAuth token for your service. Chataway never tells you who the user is on Chataway.
#Can I ask users for an API key instead of OAuth?
No. Store apps can't declare secrets, and forms may not ask for keys. Offer OAuth — a public client with PKCE — even if it's a thin layer over your API keys. (Local apps are different: they declare contributes.secrets, which the user enters in the app's settings.)
#Can I charge through Chataway?
Not yet. Bill on your own service. If a tool spends money or credits, say how much on its confirm card.
#Development
#My tool doesn't show up in the chat.
Start a new chat — tools attach when a session starts. Then check the Inspector: the tool must be declared in plugin.json and listed by your server under the same id.
#Why are my panel's scripts blocked?
The panel runs with a strict CSP in a sandbox with an opaque origin. Bundle your assets into ui/, use classic (non-module) scripts, and call only hosts in remote.domains. See Panels.
#Can I test without the desktop app?
Partly. npm run ui runs your panel in a browser against a mock host, and your MCP server is testable with any MCP client (for example the MCP Inspector). The full flow — cards, files, accounts — needs chataway dev.
#Can I develop against a staging server?
Yes: npx chataway dev --mcp-url https://staging.example.com/mcp.
#My local app works for me but not for people who install it from GitHub.
It runs isolated for them. Usually it's one of: a ctx call that isn't awaited, a host missing from network.domains (blocked requests show in the Inspector), a program started without the exec grant, or an import from outside the app's folder. Switch on Run isolated on your app's page to reproduce it.
#Publishing
#How long does review take?
Updates from verified publishers that don't ask for more access are published within seconds. Human reviews — first versions, permission changes, unverified publishers — depend on the queue; you're notified in the dashboard and by push when it's done.
#I need to fix a bug urgently.
Most fixes are server-side: deploy your server, no new version needed. If the panel or manifest must change without widening permissions, a verified publisher's update is auto-approved.
#Can I transfer an app to another publisher?
Not yourself — the id is bound to the publisher that first uploaded it. Contact us from the developer dashboard.
#Can I unpublish?
You can unlist an app in the dashboard (existing installs keep working). To withdraw a specific version from every Mac, ask for it to be yanked.
#Is there a revenue share?
There's nothing to share: the store doesn't sell apps. Your business runs on your service.