Decide who should operate the deployment
Start with the operational choice. Running a host's CLI yourself gives your team responsibility for its account, environment configuration and release process. A provider-specific agent integration can automate those actions while keeping that provider's operating model. SpringRoll supplies a workspace record and managed hosting handoff for source you continue maintaining in your Codex project.
Choose SpringRoll when ownership, immutable releases, deployment workflow and a place for colleagues to launch the app belong together. Choose direct hosting when your existing platform team already supplies those responsibilities and you intend to integrate with its process. Neither choice fixes an application that cannot build outside your machine. Before configuring MCP, reproduce the production build and write down the task a colleague will test.
Step 1: register the remote server in Codex CLI
Run the catalog's command below. The --url option selects a streamable HTTP server instead of starting a local stdio process. It names the connection springroll so subsequent MCP actions can refer to it. Keep the endpoint public and reachable; a localhost URL refers to the client machine and is unsuitable for a hosted client accessing your organization.
Codex stores MCP settings in its configuration, commonly ~/.codex/config.toml. OpenAI documents user and trusted project configuration. Inspect the effective configuration in the session you will use, particularly if your team maintains project settings or you use both the CLI and an editor integration. Do not place OAuth credentials or a copied private configuration in your source repository.
codex mcp add springroll --url https://springroll.dev/api/mcpStep 2: finish OAuth before requesting workspace work
Follow the authorization flow that Codex opens for the remote server. Sign in to SpringRoll, select the intended workspace and review the requested access. A server being present in configuration proves only that it was registered. Public discovery may succeed before authenticated workspace operations are available, so verify authorization rather than treating a visible tool list as a successful login.
If your Codex version leaves OAuth pending, use the MCP login action documented by that CLI version. The official documentation describes a separate login when credentials have not yet been resolved. Keep the browser callback on the machine that initiated login. A callback failure in a remote shell is an authorization problem to resolve before asking the agent to deploy repeatedly.
The resulting SpringRoll authorization inherits the member's permissions and does not permit human approval decisions. Choose the member and workspace carefully. A Tenant Admin's policy still decides whether an operation may proceed; asking Codex to bypass a denied change cannot grant it access.
Step 3: submit the source with explicit runtime requirements
Give Codex the prompt below from the application repository. Review its proposed app name, owner and support contact. Ask it to inspect the package scripts and framework configuration, then state the production build command and output location. Include required environment variable names, storage needs and any services that must remain outside the web request lifecycle.
Have it show whether the workspace uses Direct to Production or Staged. Direct is the default; configure the staged path first if a reviewer must assess Development and UAT before Production. Review placement against the actual workload. An estimate on a receipt describes its recorded assumptions rather than a guarantee that every usage pattern will cost the same.
After submission, retain the application, release and deployment references. Inspect the deployment's returned status and continue following it to the actual result. A failure needs its build error and a corrected release. Avoid resubmitting unchanged work just because the first call returned before the asynchronous build completed.
Prepare this project for SpringRoll. Check the build, workspace, owner and deployment workflow; tell me the target environment, then deploy and follow the build to its actual result.Step 4: test the deployment as a colleague
When the deployment reaches READY, open the working URL outside the development server. Complete the task you wrote down at the start, including a save or read if the app uses one. Compare output with a known fixture. Check the deployed environment's variables and services rather than trusting values that happened to exist in your terminal.
Select the portal audience, copy the appropriate SpringRoll app link and test with two identities: one allowed and one denied. Test and Production should be verified separately for staged apps. Keep the original provider URL in the verification record too, because it relies on application or provider authentication. Finish by handing over the owner and support details alongside the link.
Check five local assumptions that fail after shipping
A hard-coded localhost service may work in Codex's development environment and fail in a colleague's browser. Move the endpoint into deployment configuration and check the request from the deployed app. Missing environment variables are a separate failure: list names without exposing values, set them in the intended environment and repeat the production build or runtime check as appropriate.
Treat local SQLite databases and filesystem uploads as explicit persistence requirements. Use durable shared storage for company records and verify that two sessions see consistent state. Long-running workers require an execution model supported by the chosen workload; a web request is not an indefinite job runner. Inspect client-side assets for embedded secrets, rotate exposed credentials and move privileged operations behind a server-side boundary.
Troubleshoot Codex configuration and session boundaries
If the server is missing, check the configuration that the current Codex process loads and restart or refresh the session after adding the connection. Review project trust and enabled-server settings in the official documentation. An entry under the wrong configuration root can leave one terminal connected while another session has no SpringRoll tools.
Separate the coding sandbox from the remote authorization. Permission to read a local repository does not authorize a SpringRoll workspace. Likewise, browser sign-in does not establish that Codex can package the files it needs. When an operation fails, preserve its error code and correlation reference, determine which boundary rejected it and fix that boundary before retrying.
Use the current tool catalog rather than remembered arguments from an old chat. Discovery describes available tools and schemas; authenticated calls then apply the selected member's permissions. For a guided end-to-end example with a dependency-free static build, work through the deployment guide before adapting a full-stack repository.
Frequently asked questions
Does Codex need a pasted SpringRoll token?
An OAuth-capable remote MCP connection uses browser authorization. Manual agent tokens are a separate fallback for clients that do not support that flow.
Can I reuse the existing repository?
Yes. Keep the application source in your project and prepare a production build that fits a supported workload. SpringRoll records the submitted release and deployment.
Is a queued deployment ready to share?
No. Follow the actual status to READY, open the deployed app and run its core task before handing colleagues a launch link.
Will authorizing Codex grant new company data access?
No. Data access requires its own environment-specific grant and, where required, a person's approval. A coding session does not inherit every data source the member can reach elsewhere.