Read your cards and documents from Codex through MCP. For a coding mission launched from Stellary, connect Desktop to the local repository and follow the result in the card.
Codex
Connected
Stellary
Launch workspace
MCP gives the client access to the project. Desktop lets Stellary launch a mission in the linked repository. Choose the path that matches your task.
01
Install and sign in to Codex on the target machine.
02
Refresh Stellary Desktop until the Codex runner and models are ready.
03
Connect the project to the exact local repository folder.
04
Assign the card to the agent configured with the Codex target.
05
Read the mission trace and review the delivered result.
Mission STL-128
Install and sign in to Codex on the target machine.
Checklist
Linked context
A project-repository link tells the runner where the coding mission belongs.
Codex works locally while Stellary remains the shared source for the card, project context, execution state, and team review.
A project-repository link tells the runner where the coding mission belongs.
Only ready models shared with the workspace are available to other members and agents.
Queued, running, blocked, failed, cancelled, and completed states stay explicit.
The login command opens Stellary consent in the browser. Select the workspace and access you need.
codex mcp add stellary --url https://api.stellary.co/mcp
codex mcp login stellary
codex mcp listConfiguration in ~/.codex/config.toml. Set STELLARY_MCP_TOKEN in the client environment before starting it. A projects:read personal token is enough to explore the project as yourself; an agent mission needs the appropriate identity and permissions.
[mcp_servers.stellary]
url = "https://api.stellary.co/mcp"
bearer_token_env_var = "STELLARY_MCP_TOKEN"Configuration documentation checked on .
Sources and terms to review
Install a recent Codex version and check that its help includes the MCP commands above. Your AI provider account and your Stellary connection are separate credentials.
Create a Stellary project with a test card, a precise objective, and a context document. Reading this data through MCP does not require a local repository or Desktop.
After OAuth consent, open /mcp in the client and check that Stellary is available. Ask: “Call stellary_init, list the projects I can access, then summarize the test card’s acceptance criteria. Do not modify any objects.”
The check succeeds when the client finds the right project and the criteria actually written in the card. Use IDs returned by list_projects for subsequent calls. Adding a server to configuration does not prove this access.
To launch Codex from a card, install and authenticate its CLI on the repository machine. In Stellary Desktop, refresh the runners, share the available runner with the workspace, then link the exact Git folder to the project.
Configure an agent for local execution with Codex. Prepare a card: “Read the README and repository scripts. Propose a verification plan with the relevant commands, without changing files.” Launch the mission and wait for its result in the card Activity.
A 401 response indicates missing, expired, or revoked access. Reconnect OAuth, or check the token and environment variable in the client process.
For a 403 response, check scopes, role, and project access. If a tool is not advertised, also check the selected identity and the agent tool policy.
A remote MCP connection gives access to the hosted project. A Desktop mission runs on the connected machine; this does not mean the AI model runs locally.
The model provider can receive the context needed for the request and apply its own access or billing terms. Check the selected model and allowed data before sending a sensitive document.
From Codex, an already authorized agent identity initialized Stellary, opened a mission in the demonstration project, created a card containing fictional data, then read its title and description through MCP. Both fields matched the submitted content.
This check verifies card creation and retrieval on the hosted service. It does not validate a fresh OAuth connection, a Desktop mission, or autonomous application delivery. The protocol and its limits are available in the check record below.
Standalone Codex session
Stellary-managed mission
Source of work
Standalone Codex session
A prompt entered in the current terminal.
Stellary-managed mission
A card with owner, context, and success criteria.
Repository
Standalone Codex session
Current working directory.
Stellary-managed mission
Repository explicitly linked to the project.
Status
Standalone Codex session
Known by the terminal user.
Stellary-managed mission
Visible from the board and Activity.
Review
Standalone Codex session
Coordinated separately.
Stellary-managed mission
Attached to the original card and mission.
Stellary connects to the Codex CLI installed and authenticated on your machine. Availability and model choices depend on that local runner and what the workspace shares.
Yes, provided each project is linked to the correct repository and the machine is authorized and available. The runner receives the mission with its project target.
Mission cancellation is part of the execution lifecycle. The runtime must honor the cancellation and return a visible state to Stellary.
Yes. Add the remote server and connect Stellary with OAuth, or use a token through an environment variable. This path provides project tools; Desktop lets you launch missions from Stellary.
Link one repository and run the first bounded coding mission from Stellary.
Create your first mission