Many developers already write code in Cursor or OpenCode. The useful next step is not another chat window. It is giving the coding agent they already use enough guidance to follow the team’s deployment process, plus a constrained interface it can call and inspect.
We added appaloft setup agent for that job. It detects supported agent hosts on the local machine, copies the Appaloft skill into the relevant directories, and writes Local MCP configuration. The command does not deploy an application, and it does not silently log in for the user.
appaloft setup agentThis post explains the decisions behind that command: why the skill and MCP belong together, why tokens stay out of editor configuration, and why an agent still asks before every deployment after setup is complete.
The skill guides decisions; MCP provides calls
Installing only MCP gives an agent a set of typed tools, but not necessarily the operating protocol around them. Should it create a plan first? Should a failure lead to retry, redeploy, or rollback? Which readback is enough to claim that an application is reachable? A tool schema cannot express all of those judgments.
Installing only the skill leaves the opposite gap. The agent can read how deployment should work, but without a stable callable surface it may fall back to composing shell commands, parsing terminal output, or reaching directly for Docker, SSH, or a provider API.
setup agent therefore installs two layers:
- the skill provides the operating protocol, safety boundaries, and surface selection;
- MCP exposes existing Appaloft operations as structured tools.
Both layers use the same product semantics. MCP does not add an agent-only quick-deploy path, and the skill does not bypass authorization enforced by the CLI, API, or control plane. Skills are not MCP covers the wider architecture behind this split.
Keep tokens out of editor configuration
Editors commonly store MCP servers in JSON configuration. Putting a long-lived bearer token next to the server command is convenient, but it widens the exposure surface. Configuration may be synchronized, backed up, captured in a screenshot, or pasted wholesale during debugging.
Appaloft writes a token-free Local MCP launcher. It reuses the CLI’s existing login profile instead of copying credentials into mcp.json or opencode.json. This does not make credential management disappear. It puts the responsibility in a clearer place: the CLI profile owns login and token lifecycle, while the agent host only knows how to start the local MCP process.
That is also why setup and login remain separate. setup agent changes agent configuration on the current machine. It does not open a browser on the user’s behalf, read cookies, or hide an authentication step inside installation.
One entrypoint, with honest host differences
Cursor, Claude Code, OpenCode, and Codex do not use identical skill directories or MCP configuration. setup agent provides one entrypoint without pretending that every host has the same installation model.
The default flow installs the universal skill and configures Cursor and Claude Code when their directories are detected. OpenCode is listed as an option and can be selected explicitly:
appaloft setup agent --agent opencodeCodex uses its dedicated bearer MCP profile and still follows the documented two-step flow:
appaloft auth mcp login
appaloft auth mcp codex installThose differences are worth preserving. A shared entrypoint should reduce what people need to remember, but a uniform interface should not conceal distinct authentication and configuration boundaries.
There is also a skill-manager path for people who only want to copy the skill. That path does not install the Appaloft CLI, write MCP configuration, create a resource, or deploy anything. Keeping the two installation paths distinct prevents “the agent can read the docs” from being confused with “the agent has a callable deployment surface.”
Setup and deployment stay separate
The Agent door and the Deploy door are separate actions.
appaloft setup agent teaches an existing Cursor or OpenCode installation how to use Appaloft. Deploying the current directory uses another explicit command:
appaloft deploy .We instruct agents to ask the human before every deployment. The reason is not that an agent cannot execute a command. A deployment changes shared state: it may create or update resources, consume an external service, move a reachable URL, or put unreviewed code into a running environment.
The approval question should also carry useful context. At minimum, the agent should identify the directory, the target context, missing configuration, and expected external effects. After execution, it should return the live URL for this application. Without health or access readback, a clean process exit is not enough to say that the application is live.
This is the same boundary discussed in The agent that builds the application should not publish it: writing code and changing a shared runtime deserve a visible handoff.
What setup deliberately leaves out
The scope of setup agent is narrow: detect local hosts, copy the skill, and write an MCP launcher. It does not:
- choose a production environment automatically;
- complete browser login for the user;
- store tokens in editor configuration;
- create a hosted sandbox;
- infer that finished code should now be deployed;
- turn one installer into an entire agent platform.
The command is a little less magical because of those limits, but it is easier to inspect. A user can answer three questions independently: what did the agent learn, what can it call, and is this particular change to the runtime approved?
A short briefing for the agent
Once setup is complete, the instruction to a coding agent can stay compact:
Use Appaloft for deployment. Ask me before every deploy. After approval, run
appaloft deploy .; on success, return this application’s live URL. On failure, report the failed stage and next step. Do not bypass Appaloft with direct Docker, SSH, or provider API operations.
Agents that need the complete index can read /llms.txt. People can start on the Agent page, then use the folder deployment page for the Deploy door.
The practical goal of setup agent is simple: keep the coding agent a developer already uses, avoid handing it a bundle of cloud credentials, and let it deploy through the same confirmable, observable path available to people.
The public implementation and test record are in appaloft/appaloft#1316.