OpenCode

Real OpenCode.
Inside the builder.

OpenCode runs alongside the Relpin builder against the actual TypeScript project, with server-side credentials, governed file authority, and pinned releases. No local IDE, no detached chat loop.

Start building See the workflow

Browser-based Real project Governed runtime

Relpin Studio

Button.tsx

Button.test.tsx

theme.css

1import { cn } from '@/lib/utils'

3type Variant = 'default' | 'destructive' | 'ghost'

5export function Button({ children, variant = 'default' }: { children: ReactNode, variant?: Variant }) {

6 return (

7 <button className={cn('btn', `btn-${variant}`)}>

8 {children}

9 </button>

10 )

11}

OpenCode

Kimi K2.6 — Coding

Connected

Today

You 10:12

/review src/components/Button.tsx

Working live In progress

Read project files 00:04

src/components, theme.css, tsconfig

Inspect Button.tsx 00:02

Variants, props, a11y attributes

Check patterns

Theme tokens · focus ring · prop spread

Draft review

Findings and suggested edits

Elapsed 00:12

/review app /explain file /tests /scaffold

Ask OpenCode to review, explain, or propose a change…

In-browser

Lives in the workspace.
Not in a side window.

OpenCode opens inside the Relpin builder, next to the same files, preview, and release pipeline. It reasons about the actual app project, not a sandbox or pasted snippets.

Studio session

OpenCode opens inside the builder, sharing files, preview, and credentials with the live workspace.

Real project files

Reads and edits the actual TypeScript project — no sandbox copy, no pasted snippet.

Release path

Proposals converge into the same pinned release pipeline as every other workspace edit.

In-browser

Detached chat

× Pasted snippets out of context

× No access to real project files

× Suggests changes you re-apply by hand

× Credentials end up in the browser tab

× Drifts from the deployed release

In-workspace OpenCode

✓ Opens next to files, preview, releases

✓ Reads the actual TypeScript project

✓ Edits route through the governed patch path

✓ Provider credentials stay server-side

✓ Proposals converge into a pinned release

Runs in the same browser session as the builder and preview

Reads and edits the real TypeScript project, not a sandbox copy

Shares the workspace lease — no parallel state to reconcile

Proposals stay visible before they become persisted project changes

Studio addon · Workspace lease · Project files · Release path

Authoritative files

Real file edits.
Not diff theatre.

OpenCode writes to the same TypeScript project that powers preview and release. Edits flow through the governed patch path, with the file tree as the source of truth — not a chat transcript.

Governed patch path

Edits route through the same patch pipeline as human commits — not a chat-side buffer.

File-level authority

The workspace tree is the source of truth. Reverts are file-level, not "undo last message".

Preview sync

The preview container reloads against the updated project graph as soon as the patch lands.

src/components/Button.tsx— Edit existing file

Project Files

src/

components/

~Button.tsx

Button.test.tsx

StatusBadge.tsx

lib/

utils.ts

1 file modified · +2 / -2 lines · preview reloaded

Diffsrc/components/Button.tsx

import { cn } from '@/lib/utils'

-type Variant = 'default' | 'destructive'

+type Variant = 'default' | 'destructive' | 'ghost' | 'outline'

export function Button({ children, variant = 'default' }: Props) {

return (

- <button className={cn('btn', `btn-${variant}`)}>

+ <button className={cn('btn', variants[variant])}>

{children}

</button>

)

}

Edits land in the workspace project, not a copy

Patches converge with the same pipeline as human commits

Preview reloads against the updated project graph

Reverts are file-level — not "undo last chat message"

Governed patches · Workspace tree · Preview reload · File-level revert

Role authority

Authority is a role grant.
Not a prompt setting.

Orgs grant OpenCode through the same RBAC model that governs the rest of the workspace. A role decides whether a session may inspect, author through the governed patch path, or only queue edits for approval — independent of what the prompt asks.

01 Viewer

Role grant

Inspect-only

Read and explain the project. No writes — for roles meant to review, not author.

02 Builder

Role grant

Direct authoring

Write through the governed patch path. For roles trusted to change the project.

03 Reviewer

Role grant

Approval-gated

Queue edits until a role with approval authority confirms.

Prompt

/explain src/lib/pricing.ts

Authority

VIEWERInspect-only

allowed

No file writes. The role grants read, not authoring.

OpenCode session

~Read src/lib/pricing.ts (148 lines)

·Inspect type signatures and exports

·Cross-reference usePricing.ts hook

>Returns annotated walk-through to chat

Authority is assigned to roles, not toggled per prompt

The same RBAC model that governs the workspace governs OpenCode

Orgs decide which roles may inspect, author, or approve

Access to OpenCode itself is a capability grant on the role

Role-governed · Inspect · Author · Approve · Org-managed

Governance gates

OpenCode proposes.
Relpin authorizes.

OpenCode operates inside the workspace's authority model. Whatever the user, AGENTS.md, or model prompt asks for, what actually persists is decided by Relpin's role permissions — not by the prompt. The platform owns the authoritative file plane.

OpenCode instructions are advisory. Relpin permissions are authoritative.

01 capability:studio:opencode

Access

OpenCode is an addon gated by an org capability. Roles without the grant never start a session — hiding the entry point is UX; the backend refuses it regardless.

02 action:studio:authoring:exec

Authoring

A session only runs the authoring actions its role is permitted. Read access never implies write access.

03 project path

File authority

Writes converge through the governed project path, classified by target. The container filesystem is never the source of truth, and secrets are never writable.

04 server-side

Credentials

Provider keys are stored server-side and scoped per environment. They are never sent to the browser or exposed to the session.

05 runtime credits

Runtime

Relpin meters container and session time as runtime credits. Provider token spend stays on your own account.

06 audit log

Audit

Every session and write — allowed or denied — records actor, app, environment, path class, decision, and session id.

Direction

Relpin is separating review, chat, edit, dependency, and publish into independent AI permissions — so an org can allow "review my app" without allowing "the agent edits my app." Rolling out as the permission model lands.

Authority holds even when a prompt or AGENTS.md asks for unrestricted edits

OpenCode access is an org capability granted to roles

What persists is gated by the role's authoring and publish permissions

Every decision — allowed or denied — lands in the same audit stream

Access · Authoring · Files · Credentials · Runtime · Audit

Audit trail

Every action attributable.
Every write reviewable.

OpenCode actions are recorded against actor, app, environment, and session. Allowed edits, denied edits, reads, and approvals share the same immutable audit stream as the rest of Relpin.

Immutable log

Every action recorded once and never rewritten — allowed, denied, and pending alike.

Per-actor attribution

User, agent, and reviewer identities captured per event with the rule that gated the action.

Per-environment scope

DEV, TEST, and PROD events queryable independently through the same audit surface.

Audit stream · sample data

streaming

Actor

Action

Target

Time

Status

ymalinovskiy

opencode.write

src/components/StatusBadge.tsx