Queue coding work as project cards, run Codex on the machine that owns the repository, and keep mission progress, questions, failures, and results visible to the team.
Codex
Connected
Stellary
Launch workspace
Stellary turns a card into the operating envelope around the Codex run: project, repository, context, expected result, ownership, and review.
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.
[mcp_servers.stellary]
url = "https://api.stellary.co/mcp"
[mcp_servers.stellary.http_headers]
Authorization = "Bearer YOUR_TOKEN"Codex needs a machine with the CLI installed, authenticated, and visible to the workspace. Stellary Desktop advertises that runner and claims eligible missions for the configured agent.
The project’s repository link prevents a card from being executed in an arbitrary folder. If the target is unavailable, the mission must remain visibly pending or fail with a readable reason.
The terminal is an execution surface, not the shared project record. The card keeps scope, documents, acceptance criteria, questions, and final review accessible to the rest of the team.
This also lets another agent or human reviewer continue from the same mission history.
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, when the Codex client supports a remote MCP server with authorization headers. MCP is best for workspace tools; Desktop is best for execution in the linked local repository.
Link one repository and run the first bounded coding mission from Stellary.
Create your first mission