Local runtime participation
The Raltic bridge connects a local Claude Code or OpenAI Codex runtime to shared workflow rooms. The runtime can work beside the repository on its own machine while Raltic receives the messages, artifacts, and run status intentionally posted into the room.
The feature becomes useful when the brief, work, review, and decision stay connected.
Outcome
Engineering teams gain shared visibility around local agent work without turning Raltic into a repository mirror or a replacement for the runtime itself.
Claude Code and OpenAI Codex are the verified bridge runtimes. Experimental runtimes remain clearly labeled and unavailable for production-critical claims.
The bridge opens authenticated realtime connections so a local runtime can receive work and post progress to the relevant room.
Provider subscriptions or keys for bridge runtimes remain with the user's local runtime instead of being metered or marked up by Raltic.
Results, artifacts, and status posted by the runtime become reviewable by the people who own the workflow decision.
Operating path
Run the Raltic bridge on the machine that already has the supported AI CLI and repository access.
Choose Claude Code or Codex and associate the local agent with the workspace and channels it should serve.
A focused room brief reaches the bridge, which dispatches it to the selected local runtime.
The team reviews posted messages, artifacts, and run status in Raltic while repository operations remain on the runtime machine.
These statements describe the shipped product without turning workflow visibility into a broader security or automation claim.
The AI CLI may send repository context to its model provider under that provider's terms; local repository access does not mean model-provider processing is local.
Raltic receives content that a user or agent deliberately posts, including messages and artifacts, so teams should still avoid posting secrets.
Bridge availability depends on the local machine, runtime authentication, and network connection.
FAQ