Use this path when the code already exists and the missing piece is a controlled handoff into an application your team can review and open. The coding agent still writes the application. SpringRoll governs what happens after the repository is ready.
Before you start
You need a SpringRoll workspace, a supported Codex or Claude client, a Git repository the workspace can deploy, and a configured runtime. For a first walkthrough, use a small public repository with no secrets or private data.
Keep secrets out of the prompt. Never paste a runtime token, database password, magic link, source credential, or private customer value into a coding-agent conversation, issue, commit, or screenshot.
1. Create the workspace
Open SpringRoll signup, enter the work email, and use the one-time verification link. The link expires after 15 minutes and works once. Request a new one instead of forwarding or reusing an expired URL.
2. Connect Codex or Claude
Open Onboarding in the new workspace, choose the coding client, and follow the displayed install and authorization steps. The product shows the current client-specific instructions because those capabilities can change.
Connection is complete only after SpringRoll holds an active authorization grant for that workspace member. Copying the install command alone is not completion. The public docs explain the MCP endpoint and authorization model.
3. Register the application
Ask the connected agent to register the application from its Git repository. Confirm the application name, source, owner, data classification, and target environment before deployment. SpringRoll writes the tenant-scoped application record and its audit event together.
4. Request the deployment
Ask the agent to deploy the registered revision. SpringRoll pins the release, creates the deployment record, writes the audit event, and hands the build to the configured runtime.
Git source → application record → immutable release → runtime build → deployment state
Creating the deployment is not success. BUILDING and other intermediate states mean the handoff is still in progress. Preserve any returned failure instead of creating repeated deployments to hide it.
5. Wait for READY
Follow the deployment state in SpringRoll. The governed URL is ready to open only after the runtime reports READY. This is also the canonical creator activation point: first_deployment_ready records the first real ready deployment, not the creation of a deployment row.
6. Review and invite
Review the source revision, environment, URL, ownership, and audit history. If the workspace uses a staged workflow, send the approval through that path. Invite a coworker only after checking the recipient and the application audience; invitation links are one-use and time-bounded.
If the flow stops
The magic link did not arrive
Check spam, then request a fresh link while the previous 15-minute window is closing. Contact SpringRoll support if delivery remains missing.
The agent is not connected
Return to Onboarding and repeat the displayed authorization step. A copied command without a completed grant is not enough.
The deployment never reaches READY
Open the deployment detail and preserve the exact error and deployment ID. Check repository access and workspace runtime configuration before retrying.
What SpringRoll governs
SpringRoll governs registration, ownership, releases, environments, deployment state, approvals, policy, and audit history. Codex or Claude still writes the code, and the deployment runtime still builds and hosts it. That separation adds control without pretending SpringRoll is another coding model.
See the same path as a no-account product walkthrough, or create a workspace when you are ready to run it.