Railway CLI について
Railway CLI はローカルプロジェクトを Railway にリンクしてターミナルから直接デプロイできます。プロジェクトのリンク、サービス変数を使用した実行、変更のデプロイ、ログの検査により、ローカルからクラウドへのシームレスなワークフローをサポートしています。
主な機能
- 01railway login と railway link でローカルプロジェクトを Railway にリンク
- 02railway up でリモートサーバーにプロジェクト変更をデプロイ
- 03Railway 環境から注入されたサービス変数を使用してローカルで実行
- 04ライブデプロイログを検査してアプリケーションの状態を監視
活用シーン
- 01ローカル開発プロジェクトを Railway に最小限のセットアップでデプロイ
- 02アプリケーション環境変数とサービス設定を管理
- 03デプロイを監視して本番環境の問題をトラブルシューティング
インストール
OS またはパッケージマネージャーを選び、コマンドをターミナルで実行します。
インストール後にrailway --versionを実行して確認します。
コマンド例
よく使うコマンドを使う順に並べています。
詳細
Railway CLI
Railway CLI を使用すると、コマンドラインから Railway プロジェクトを操作できます。CLI のドキュメントをご覧ください。
インストール
エージェントのサポートを設定しながら、1 ステップで Railway CLI をインストールできます(macOS、Linux、Windows は WSL 経由):
bash <(curl -fsSL railway.com/install.sh) --agents -y
CLI が ~/.railway/bin にインストールされ、検出されたエージェントツールを設定するために railway setup agent が実行されます。
エージェント設定を行わずに CLI をインストールするには:
bash <(curl -fsSL railway.com/install.sh) -y
CLI をアンインストールするには:
bash <(curl -fsSL cli.new) -r
その他のインストール方法については、CLI のドキュメントをご覧ください:Homebrew、npm、Scoop、ビルド済みバイナリ、ソースからのビルド。
IaC の部分所有権
railway config partials list を使って、名前付きパーシャルと、それらが所有する
リソースアドレスを確認できます。railway config partials release NAME はパーシャルの
所有権を解除し、railway config partials transfer FROM TO は別のパーシャルに
移します。リソースを選択するには --resource ADDRESS オプションを複数指定します。
省略すると、ソースパーシャル全体が対象になります。--dry-run を使うと、対象となる
正確なアドレスを事前に確認できます。
これらのコマンドは元の作成ファイルがなくても機能し、所有権のメタデータのみを変更します。 確認方法、JSON/CI での使用方法、プロジェクト全体の管理に戻す方法については、 IaC ガイドをご覧ください。
認証
CLI を使用する前に、Railway アカウントで認証してください:
railway login
SSH セッションなど、ブラウザーを使用できない環境では、ブラウザーレスログインを使用してください:
railway login --browserless
トークン
CI/CD パイプラインでは、対話型ログインの代わりに環境変数を設定してください:
- プロジェクトトークン:プロジェクトレベルの操作には
RAILWAY_TOKENを設定します。 - アカウントまたはワークスペースのトークン:アカウントレベルまたはワークスペースレベルの操作には
RAILWAY_API_TOKENを設定します。
RAILWAY_TOKEN=xxx railway up
詳しくはトークンをご覧ください。
エージェントのセットアップ
AI コーディングツール向けに Railway のエージェントサポートを設定します:
railway setup agent -y
これにより Railway スキルがインストールされ、検出されたツール(Claude Code、Cursor、Codex、OpenCode、GitHub Copilot、Factory Droid、Pi、Antigravity など)向けに、リモート Railway MCP サーバー(railway mcp proxy 経由で mcp.railway.com に接続し、CLI のログイン情報で認証)が設定されます。
セットアップの一部だけが必要な場合は、個別のコマンドを使用してください:
railway mcp install --agent cursor
railway skills --agent claude-code
自動更新を有効にすると、CLI が管理するスキルはバックグラウンドで自動的に更新されます。
CLI のバージョン変更後、最初に通常のコマンドを実行したときも更新されます(railway upgrade
またはパッケージマネージャーによるアップグレードのどちらの場合も同様です)。ローカルで
変更または削除されたスキルはスキップされ、ユーザーが追加したファイルは保持されます。
更新されたスキルを読み込むには、コーディングツールを再起動してください。スキップされた
更新を確認するには railway skills update を使用します。ローカルの変更を明示的に
上書きするには、--force を追加してください。
railway autoupdate disable(または RAILWAY_NO_AUTO_UPDATE=1)を指定すると、CLI と
スキルの自動更新、および更新通知が無効になります。明示的な railway upgrade、
railway check-updates、railway skills update コマンドは引き続き使用できます。
代わりに、ローカルの GraphQL ベースの MCP サーバーを有効にするには:
railway setup agent -y --local
# or
railway mcp install --local --agent cursor
VM の起動、再接続、デスクトップのセットアップ、認証の詳細については、 cloud-agent コマンドガイドをご覧ください。
進行状況とステータスの更新
railway upgrade は、CLI のインストールと管理対象スキルの同期を1つのフローとして実行します。作業の完了に合わせてステージが進み、最後の概要では、新しいバージョンが有効になったか、次回のコマンドから使用されるかが示されます。この明示的なコマンドでは、自動更新が無効になっている場合も管理対象スキルを同期します。
自動検出とダウンロードは、通知を表示せずに実行されます。新しい CLI が有効になり、スキルの同期が完了すると、対話型コマンドでは CLI のバージョンごとに完了通知が1件表示されます。保持されたローカルの編集内容は中立的に報告され、スキル同期の失敗は、CLI のインストール成功とは別に報告されます。JSON、パイプ出力、ヘルプ、バージョン表示を使用するコマンドでは、完了通知は表示も消費もされません。手動でのアップグレードが必要なインストール方法では、リリースごとに利用可能になったことを1回通知します。
実行中のバージョンと記録されたインストール済みバージョン、準備済み/進行中の CLI 更新、スキル同期の結果、未管理のスキルを確認するには、railway autoupdate status を実行します。スキルの詳細な結果を確認するか、同期を再試行するには、railway skills update を使用します。
クラウドエージェントの起動時のデフォルト
--codex、--opencode、--claude、--grok、または --railway を指定した railway code の各呼び出しでは、新しい VM が作成されます。これは remote、Codex の desktop-only、および -- の後に指定するハーネス引数にも適用されます。--new は指定できますが、省略可能です。既存のバックエンドには connect [agent]、サーバーを明示的にセットアップするには --agent <name-or-id>、シェルを開くには railway ca ssh <agent> を使用します。引数なしの起動と、共有 CA/Desktop のプロビジョニングでは、従来のターゲット指定動作が維持されます。
ローカル Railway TUI プロトタイプ
railway code --railway # new VM, local TUI on its public agent endpoint
railway code --railway --agent my-box --dir /app/project
railway code --railway connect my-box # connect to an existing VM; wake it if asleep
railway code --railway remote # run the TUI on a new VM over SSH
railway code --railway --connection-json # setup and verify, without opening a TUI
railway code get-config my-box # replay saved connection details
railway code --railway は新しい VM を作成し、Codex や OpenCode と同じセットアップの進行状況とターミナルフレームを使って、Railway CA セッションペインでクライアントを開きます。connect は既存の VM を再利用する場合にのみ使います。通常の起動には必要ありません。セットアップ時に特定の既存 VM を指定するには、--agent my-box を使います。会話サイドバーには、デーモンのネイティブセッションが一覧表示され、再開できます。
ローカルの railway-agent-tui は、既存の CloudAgent.agentWsUrl(wss://<agent-domain>/agent)に WebSocket で接続します。ダッシュボードのチャットや VM の TUI と、プラットフォームが監視する railway-agent serve デーモンおよび永続セッションを共有します。VM を作成または起動すると、そのデーモンが起動します。ランチャーは TUI を開く前に、get_state を使ってパブリック制御プロトコルを検証します。2 つ目のデーモンを起動することも、code-* ドメインを要求することもありません。--dir はリモートプロジェクトを選択し、既定値は /app です。再接続時は、利用可能であればローカルに保存されたディレクトリを使います。名前を指定しない場合は、通常のクラウドエージェント選択が適用されます。エージェントエンドポイントを持たない古い VM では、その制限が通知されます。
ゲートウェイは、WebSocket のアップグレードごとに cloudAgentHarnessToken から有効期限が 5 分の JWT を取得します。小さなローカル WebSocket ブリッジが、再接続やセッション切り替えを含む TUI 接続のたびに新しいトークンを発行します。これはパブリック WSS データパスであり、SSH トンネルは使いません。ローカルブリッジには独自のランダムなケイパビリティが必要で、TUI の終了時にはブリッジとその接続の両方が閉じます。アップグレードトークンの有効期限が切れても、開いている会話は中断されません。有効期限付きのゲートトークンは get-config に保存されず、TUI に渡されることもありません。モデルの認証情報とツールの実行は VM 上にとどまります。
ローカルでの起動、再接続、--connection-json の呼び出しでは、いずれもパブリックなエージェントリリースリポジトリにある最新の安定版を確認します。クライアントがない場合や古い場合は、バンドルされたデーモンとともに ~/.railway/runtimes/railway-tui/<version>/ に自動インストールされます。最新バージョンと一致するインストール済みクライアントは再利用されます。ファイルを置き換える前に、リリースアセットの SHA-256 ダイジェストと照合してダウンロードを検証します。ダウンロードに失敗しても、以前にインストールされたバージョンはそのまま残ります。クライアントにはアタッチに対応したリリース(v0.1.15 以降)が必要です。サーバーバージョンは VM イメージが管理します。リリースには使用するプラットフォーム用のアセットが必要です。Windows ユーザーは WSL または remote が必要です。
TUI は CA フレーム内で開き、キー操作ですぐに会話サイドバーを表示できます。--connection-json は、認証情報を含めずにパブリック URL、リモートディレクトリ、クライアントバージョン、トークン発行メタデータを返します。再度開くには、get-config の再接続コマンドを使います。明示的な remote と、そのまま渡されるハーネス引数は、引き続き VM ホストで実行されます。
コーディングバックエンドとアプリのエンドポイント
code-* エンドポイントはオプションで、VM の作成時にのみ設定できます。
通常のクラウドエージェントは、デフォルトではこのエンドポイントを要求しません。
管理対象の Codex/OpenCode クライアントのセットアップでは、VM の作成時に自動的に要求します。
railway code --codex --new
railway code --opencode --new
# Explicitly request the endpoint on a plain cloud agent:
railway ca create my-box --code-endpoint
# Choose a custom port instead of the default 4096:
railway code --opencode --new --code-port 5000
railway ca create my-box --code-port 5000
OpenCode Desktop のセットアップでも要求されます。SSH のみのセッションでは、code エンドポイントは不要です。API ではオプションの CloudAgentCreateInput.codeEndpoint オブジェクトを使用します。
{} を指定するとポート 4096 が選択され、{ "port": 5000 } を指定するとカスタムポートが選択され、省略すると無効になります。ポートは 1024〜65535 の範囲で、アプリのポート 8080 とゲートウェイのポート 8790 は除きます。API はこの設定に基づいて RAILWAY_CODE_PORT を注入し、FactoryVM は RAILWAY_PUBLIC_DOMAIN_<port> を注入します。呼び出し元およびブートストラップの変数で RAILWAY_CODE_PORT を上書きしたり、変数の設定によってルートを作成したりすることはできません。
code-* ドメインを持つクラウドエージェントでは、管理対象の Codex または OpenCode サーバー向けに設定されたポートが公開されます。どちらのランチャーもこのエンドポイントを使用するため、app-* ドメインとポート 8080 をアプリ用に利用できます。一度にコードポートを使用できる管理対象バックエンドは 1 つです。別のプロセスが使用している場合、セットアップ時に競合が報告されます。OpenCode のサーバー URL では、表示された認証情報を使って Web UI にもアクセスできます。
code エンドポイントのないエージェントでは、引き続き管理対象バックエンドにポート 8080 が使用されます。これは作成時の設定です。既存の VM 内で環境変数を設定したり、再接続したりしても、ドメインは割り当てられません。スリープと復帰の間も、選択したルートは保持されます。実行中の管理対象サーバーでは、現在のエンドポイントが維持されます。再起動時には、サーバーは VM に明示的に設定されたコードポートを使用します。これが設定されていない古い VM では、保存済みのポートが引き続き使用されます。設定済みの code エンドポイントでは、ドメインが利用できない場合にアプリのドメインへフォールバックすることはありません。
チェックポイントを使ってエンドポイントを追加または変更する
既存の cloudAgentCheckpointCreate ミューテーションでソースを取得し、ステータスが SUCCEEDED になるまで cloudAgentCheckpoint をポーリングします。その後、新しい VM を作成します。
railway ca create restored-box --from-checkpoint <checkpoint-id> --code-endpoint
# Or select a custom port:
railway ca create restored-box --from-checkpoint <checkpoint-id> --code-port 5000
railway code --opencode --agent restored-box
同等の API リクエストは次のとおりです。
mutation {
cloudAgentCreate(input: {
environmentId: "<same-environment-id>"
name: "restored-box"
cloudAgentCheckpointId: "<checkpoint-id>"
codeEndpoint: { port: 5000 }
}) {
id
name
domains { prefix port domain }
}
}
ディスクは、独自の ID とドメインを持つ新しい VM に復元されます。プロセスは引き継がれません。保存済みの Codex/OpenCode 認証情報とプロジェクトディレクトリは再利用され、ランチャーは新しい VM に設定されたエンドポイントを使用します。ソース VM の変数は自動的にコピーされません。必要な変数を渡すか、ブートストラップを使用してください。チェックポイントとブートストラップによる作成では、明示的なオプトインが必要です。別のフォーク操作では、ソース VM の code エンドポイントとポートが保持されます。
OpenCode クライアントとリモートサーバー
クラウドエージェントで認証済みサーバーを準備し、ローカルクライアントを開きます。
railway code --opencode
railway code --opencode --name my-box
OpenCode は OpenCode V2 を指します。クラウドエージェントのイメージには公式の V2 opencode が含まれており、CLI はこれを直接起動します。OpenCode 1 はサポートされなくなり、以前のエディションフラグ --opencode2 も廃止されました。opencode がまだ 1.x の古いイメージから作成されたエージェントでは、OpenCode セッションを実行できません。セッションを起動または再開すると、次のメッセージが表示されます。
This cloud agent is on an older image whose OpenCode is not V2. Create a new agent with railway code --opencode --new.
以前の CLI リリースで opencode2 として記録された設定、保存済み接続、および VM の履歴は、OpenCode として読み込まれます。
互換性のある OpenCode Desktop のインストールに既存の設定ファイルまたはデスクトップデータベースがある場合、Railway はサーバー URL、認証情報、デフォルトサーバー、およびプロジェクトを自動的に保存します。最終出力で設定が更新されたことを確認できます。Desktop のサーバー選択画面で Railway: <agent-name> を開いてください。JSON 設定と SQLite レンダラーの状態に対応しており、以前の設定はバックアップされます。更新された設定を読み込むには、OpenCode Desktop の再起動が必要になる場合があります。設定の失敗は致命的ではなく、接続情報とともに報告されます。再試行するには、コマンドを再実行してください。
CLI は手動セットアップ用にサーバー URL、ユーザー名、パスワード、プロジェクトディレクトリも出力し、さらに Railway の再接続コマンドも表示します:
railway code --opencode connect <agent>。
対応するローカルターミナルクライアントは、Railway CA のフレーム内で自動的に起動します。対話形式の起動では、読み込みペインにプロビジョニングとクライアントセットアップが表示され、不足しているクライアントを静かにインストールします。connect で再接続すると、不足しているクライアントを先にインストールするか確認されます。拒否した場合、サーバーは稼働したままになり、接続の詳細が出力されます。保存された接続設定と Desktop 設定を表示するには railway code get-config を使用します。セットアップに失敗した場合は、その診断出力が表示されたままになります。
ローカルクライアントは、リモートサーバーのプロトコルとリリースに対して検証されます。
新しい OpenCode エージェントは oc-railg-3ed と命名されます。Codex は codex-railg-3ed、Claude Code は cc-railg-3ed、Grok は
grok-railg-3ed、Railway は rlwy-railg-3ed を使用します。これはプロジェクト名の最初の 5 文字/数字を小文字にしたものに、ランダムな 3 文字のサフィックスを付けたものです。デフォルトのクラウドエージェントプロジェクトを使用している場合、ラベルは代わりにローカルリポジトリまたはディレクトリから取得されます。
既存の名前は作成前に確認されます。--name は生成された名前を上書きします。同じ命名規則が remote と railway ca desktop にも適用されます。
ローカルクライアントを使用して既存のサーバーに再接続します:
railway code --opencode connect
railway code --opencode connect my-box
connect は、所有しているエージェント上で稼働中の OpenCode サーバーを検出します。以前の CLI が OpenCode 1 として起動したサーバーは検出も再接続もされません。railway code --opencode --new で新しいエージェントを作成してください。
一致が 1 件の場合は直接接続します。複数一致する場合は workspace/project/agent のピッカーが表示されます。名前または ID を指定するとエージェントを直接対象にでき、保存されたサーバーを起動できます。
接続すると、互換性のある Desktop インストールの設定も更新されます。
接続によって新しいエージェントが作成されたり、無関係なマシンにサーバーがインストールされたりすることはありません。
非対話型ターミナルでは、CLI はプロンプトを表示したり、ソフトウェアをインストールしたり、ターミナルクライアントを起動したりする代わりに、それでも Desktop 設定を試みて接続の詳細を出力します。複数一致する場合は名前または ID が必要です。
クライアントとサーバーの両方をクラウドエージェント内で実行するには、Railway CA で次を実行します:
railway code --opencode remote
ハーネスの起動では新しい VM が作成されます。--agent <name-or-id> は既存のものを対象にします。
ローカルクライアントのセットアップでは、--dir がリモートプロジェクトディレクトリを選択します(デフォルトは /app)。OpenCode V2 はそのサーバーの起動ディレクトリを使用するため、切り替えるには新しいエージェントが必要です。セットアップでは、Desktop と同じ生成された認証情報、HTTPS チェック、プロバイダーのサインイン動作、スキル、MCP 同期が使用されます。検出された Desktop インストールに設定を保存し、手動入力用にそれらを出力します。
稼働中のサーバーとそのパスワードは再利用されます。終了したら railway ca sleep <name> を使用してください。
ハーネス固有の引数は -- の後に置きます。例:
railway code --opencode -- run --standalone "explain this project"。
クラウドエージェントのブートストラップ
設定済みで稼働中のクラウドエージェントを、再利用可能な開始点として保存します:
railway ca bootstrap save dev --agent configured-vm
railway ca bootstrap list
railway ca bootstrap save updated --agent another-vm --default
railway ca bootstrap default dev
railway code --codex # uses your local environment default
railway code --codex --bootstrap updated # selects a named bootstrap
railway code --codex --no-bootstrap # starts with a clean VM
railway ca create scratch --bootstrap dev
railway ca ランチャーで、Target Project の下にあるブートストラップ行をクリックするか、Option+B を押します。ブートストラップが存在する場合、行には Select Bootstrap と表示され、ブートストラップごとに 1 行のコンパクトなリストが開きます。ブートストラップを選択するとローカルのデフォルトになり、Create New で新規作成、No Default で今後の Cloud Agent をブートストラップなしで開始できます。サイドバーでプロジェクトまたは環境を選択して b を押すと、同じリストが開きます。これはリストの末尾にある Create New で開き、その行の環境を使用しますが、ランチャーのプロンプト対象は変更しません。
ツリーまたはブートストラップの一覧で n を押すと、新しい VM 用のエージェントを選択できます。
ピッカーには ChatGPT Codex、Use bootstrap チェックボックス、プロジェクトのデフォルトを使用する、別のブートストラップを選択する、または何も設定せずに開始するための Option+B
ショートカットがあります。
これらの起動方法によって、保存済みのデフォルトが変更されることはありません。VM、そのセッション、またはフォーカス中のターミナル内で Option+N を押すと、ブートストラップとプロジェクトを選択できる同じ 新しい VM
ピッカーが開きます。現在の VM のプロジェクトと環境があらかじめ選択されます。起動すると新しいマシンが作成されます。
キャプチャに失敗した項目は、TUI のブートストラップピッカーに表示されません。準備完了のブートストラップと保存中のキャプチャは No Default の前に表示され、Create New は最後に表示されます。
アプリのショートカットでは Option を使います(ほかのキーボードでは Alt):ブートストラップには Option+B、対象プロジェクトには Option+T、SSH シェルには Option+O を使います。Option+Esc でキーボードのフォーカスがツリーに戻ります。Ctrl+B、Ctrl+T、Ctrl+] も互換性ショートカットとして引き続き使えます。Ctrl+C は標準の割り込み動作を維持します。
既存の VM で Enter を押すと、プライマリのコーディングエージェントのターミナルを再度開きます。CLI はその VM の設定とセッション履歴を使ってエージェントを特定します。特定できない場合は、デフォルトを使用または変更せずに選択を求めます。 ターミナルペインをクリックしてもフォーカスが変わるだけです。未表示のスレッドに接続するには、引き続きそのスレッドで Enter を押すか、ダブルクリックする必要があります。
サイドバーとターミナルの間の境界をドラッグすると、サイドバーの幅を変更できます。スレッドのテキストと水平の区切り線は、利用可能な幅いっぱいに表示されます。サイドバーには濃いグレーの単色背景があり、右側の境界線がせり出した端を示します。マウスボタンを離すと幅が保存され、次回 CLI を開いたときに復元されます。ターミナルの幅が狭い場合は、設定を変更せずに表示幅が一時的に制限されます。ドラッグ中に Escape を押すとキャンセルできます。
Create bootstrap フォームはターミナルペインの中央に表示されます。名前、任意のリポジトリ(owner/repo または HTTPS URL)、コーディングエージェント用の枠線付きフィールドと、Make default チェックボックスがあります。フィールドと Create bootstrap ボタンをクリックするか、Tab/Shift+Tab でフィールド間を移動し、左右キーでテキストを編集するかエージェントを選択し、Enter でコントロールを実行できます。フッターには利用可能なショートカットが表示されます。
作成中は、CLI が一時的な VM を作成し、選択したハーネスで利用できるローカルのサインイン情報、スキル、MCP 設定、設定をコピーし、任意でリポジトリを /app にクローンして、チェックポイントを保存する間、現在の段階がコンパクトな進行状況カードに表示されます。既存の Railway 管理下のハーネス設定は、インポートした設定より優先されます。プライベートリポジトリには VM の GitHub アクセスを使用します。キャプチャの準備ができると、CLI はデフォルトの選択を適用し、セットアップ VM を削除します。プロビジョニングまたはキャプチャに失敗した場合は、クリーンアップを試み、以前のデフォルトを維持します。クリーンアップに失敗した場合は、残っている VM の名前が表示されます。
完了後、ランチャーは変更されていないプロンプトに戻ります。サイドバーから作成した場合は、ツリーに戻ります。実際の VM を起動する場合も、現在の準備段階だけが固定幅のパネルに表示されます。
既存の実行中の VM を選択し、b を押すと、TUI 内に「名前」フォームが開きます。保存時に、ソース VM を停止、削除、切断することなく、そのディスクの内容を取得します。デフォルトが存在しない場合、「デフォルトにする」は最初からオンになり、すでに選択されている場合はオフになります。作成前に変更できます。ディスクの取得に失敗した場合、名前は予約されますが、ブートストラップとしては使用できません。同じ VM から同じ名前で再試行すると、失敗した取得レコードを再利用します。まだ保存中の場合、TUI は重複送信せず、その取得の完了を待ちます。準備完了状態のブートストラップや、他の VM から取得した名前は、このフォームでは上書きできません。サーバー側のスナップショットがタイムアウトした場合は、その失敗理由が報告されます。デフォルトが変更されるのは、取得に成功した後だけです。従来のフラットな railway ca bootstrap save コマンドでは、既存の名前の新しいバージョンを保存し、--default でそれを選択できます。デフォルトの変更は、取得の成功後に反映されます。
ブートストラップはプロジェクトと環境の組み合わせ内で共有されます。デフォルトの選択は、Railway ホストとプロジェクトも特定する環境 ID をキーとして、ローカルの Railway CLI 設定にのみ保存されます。これはダッシュボードやチームメイトのデフォルトには影響しません。ローカルのデフォルトがない場合、新しい VM はクリーンな状態で起動します。--project と --environment の明示的なフラグが優先され、次にディレクトリの Railway リンク、最後に保存された CA プロジェクト設定が使用されます。ブートストラップ名は、その環境内でのみ解決されます。list、save、default は --json に対応しています。save は、保存するブートストラップ変数用に --env-file と --variable を受け付けます。起動時の変数は、保存されたブートストラップ変数より優先されます。
ブートストラップが使われるのは新しい VM だけです。既存の VM に接続する場合、そのディスクは保持されます。削除済み、保存中、または状態が劣化したローカルのデフォルトを指定すると、エラーになります。--no-bootstrap を指定すると、明示的にこれを回避できます。ca create --from-checkpoint もデフォルトを回避し、ブートストラップ関連のフラグとは併用できません。
スナップショットには、ファイルとインストール済みのツールが含まれます。起動時やスリープ解除時にローカルサービスを再起動するには、冪等でブロッキング処理を行わない /etc/railway/bootstrap/startup.sh を使用し、セットアップに関するメモには /etc/railway/bootstrap/AGENTS.md を使用します。
ローカルターミナルまたはデスクトップクライアントで Codex を使う
永続的な Railway クラウドエージェント上の Codex App Server に接続して、コンピューター上でネイティブの Codex ターミナル UI を実行します。
railway code --codex
railway code --codex --agent my-box --dir /app
railway code --codex connect my-box
railway code --codex connect
新しい Codex エージェントには、OpenCode と同じ命名規則が適用され、codex- プレフィックスが付きます(例:codex-railg-3ed)。生成された名前は connect、get-config、クラウドエージェントのライフサイクルコマンドで使用できます。--name を指定すると、カスタム名を設定できます。
デスクトップのみのワークフローでは、次のコマンドを実行します。
railway code --codex desktop-only
railway code --codex desktop-only --agent my-box --dir /app
このコマンドは VM を準備し、認証済みのバックエンド App Server を起動または再利用して、そのパブリックエンドポイントを検証し、SSH を登録します。また、Codex Desktop が次回起動時にインポートできるように、リモートプロジェクトを保存します。その後、バックエンドを実行したまま終了します。ローカルのターミナルクライアントのインストールや起動を促すことはありません。結果パネルには、バックエンドの認証情報、SSH 設定ファイルの場所、デスクトッププロジェクト名、再接続または設定を取得するためのコマンドが表示されます。
ターミナルのセットアップでは、利用可能なローカルの Codex サインイン情報と、設定済みのスキル/MCP 同期を引き継ぎます。設定されたコードポート(デフォルトは 4096、従来の接続では 8080)で App Server を起動し、パブリック WebSocket のハンドシェイクを検証した後、Railway CA フレーム内でローカルクライアントを自動的に起動します。ツール、ファイル、スレッドは VM 上に保存されます。Codex で /resume を使用するか、CA サイドバーで会話を選択すると、リモートスレッドを再度開けます。connect は実行中の Codex サーバーを検出します。エージェントを明示的に指定した場合は、必要に応じて、以前に設定されたサーバーも起動して再起動します。ペイン内の Web リンクをクリックすると、短縮 URL やラベル付きリンクも含め、ブラウザーで開けます。
リモートターミナルクライアントは、~/.railway/codex-client/<backend-id>/ 以下に独立した永続的な CODEX_HOME を使用します。VM は自身のツールとセッションを所有しており、ローカルのみの MCP サーバー、プラグイン、フックはリモート起動に関与してはなりません。これにより、ターミナルのビジーインジケーターとキャンセル状態もバックエンドと一貫した状態に保たれます。Ctrl+C は実行中の処理を中断し、アイドル時には終了します。空のプロンプトで Ctrl+D を押すと、起動中であってもデタッチします。
ターミナル接続は、エージェントのパブリックドメイン経由で wss:// を使用します。そのベアラートークンは環境変数を介してローカルクライアントに渡されます。リモートサーバーのトークン、PID、バージョン、ディレクトリ、ログは ~/.railway/codex/ 以下にあります。明示的に選択されたエージェントでのセットアップは、バージョンが変わっていない場合、そのトークンと正常なサーバーを再利用します。ポートが使用中である場合、または実行中のプロジェクトディレクトリが異なる場合は、別のエージェントが必要です。
セットアップと connect は、railway ca desktop --codex と同じ登録を使用して、エージェントの SSH ホストを ~/.ssh/config に railway-<agent-name> として登録および検証します。再接続すると、SSH と Codex Desktop の保存済み設定の両方で、以前の railway-agent-<agent-name> デフォルトがアップグレードされます。これらは、接続とリモートプロジェクトをバックグラウンドで ~/.codex/codex-app/config.json(設定されている場合は $CODEX_HOME/codex-app/config.json)にマージします。セットアップは Codex Desktop を起動またはアクティブ化しません。アプリは次回起動時に保存済み設定をインポートします。
Codex Desktop のプロジェクトサイドバーで Railway: <name> を見つけてください。既存のカスタム SSH エイリアスとプロジェクトラベルは保持されます。connect はサーバーの実際の作業ディレクトリをインポートします。同じ VM をターミナルと Desktop の両方から使用できます。
サーバーセットアップは、npm で最新の公式 Codex リリースをサイレントに確認し、実行中のプロセスを置き換える前に、認証済みの App Server を検証します。バージョンは ~/.railway/runtimes/codex-server/<version>/ 以下にキャッシュされ、更新の診断情報は ~/.railway/codex/update.log に出力されます。更新に失敗した場合は、既存のサーバーが保持されます。connect は実行中のサーバーのバージョンを維持します。停止しているサーバーを再起動すると、更新が確認されます。ターミナルモードは、~/.railway/runtimes/codex-client/<version>/ 以下で npm を使用し、完全に一致するローカルの @openai/codex バージョンを自動的に検出またはインストールします。
スクリプト向けに、--connection-json は schemaVersion、エージェントの識別情報、および接続の url、token、directory、version、reused を含む単一の JSON オブジェクトを返します。進捗は stderr に出力されます。
railway code --codex --connection-json connect my-box
railway code --codex remote # run the UI inside Railway CA
railway code --codex -- exec "run tests" # execute inside the VM
ローカルクライアントを閉じても、サーバーは実行されたままになります。railway ca sleep my-box を使用してコンピューティングを停止し、その後 railway code --codex connect my-box で起動して再接続します。Codex は現在、そのリモート App Server トランスポートを実験的と位置づけています。
ローカル接続では、自動コマンド権限が有効になります。Codex は完全な VM アクセスと承認を無効にした状態で会話を開始、再開、フォークし、OpenCode クライアントは --auto 付きで実行されます。これらの設定は再接続時にも適用されます。Codex は、スレッドを再開する際に選択された別のリポジトリを含め、リモートプロジェクトディレクトリの信頼を記録します。
新規の OpenCode 起動では、ネイティブのホーム/スプラッシュ画面が開きます。会話はプロンプトを送信したときに作成されます。初回プロンプト付きで起動した場合は、その会話内で直接開始されます。接続の詳細は起動前に表示され、ローカルクライアントの終了後に再度表示されます。
クラウドエージェントの会話履歴
railway ca と railway code フレームでは、左側の一覧にあるクラウドエージェントを展開すると、Claude、Grok、Codex、OpenCode の会話を確認できます。タイトルを選択して Enter キーを押すと、そのスレッドを再び開きます。保存した会話はターミナルの終了後も引き続き利用できます。一覧を開いても、会話に対応するクライアントは起動しません。新しいハーネスペインは New Thread として始まり、その後、ハーネスが生成したタイトルに切り替わります。[S] は直接 VM シェルを開いた場合にのみ表示されます。ハーネスコンソール、サーバープロセス、プロビジョニングコマンドにはセッション行が表示されません。会話のメタデータは、休止中の VM を含め、再起動後もローカルにキャッシュされます。検出は起動時、稼働中のマシンを選択または展開したとき、Option+F / Alt+F でサイドバーを表示したとき、そして明示的に更新したときに実行されます。読み込み済みの行、その順序、展開状態、選択中の会話はそのまま保持されます。マシンのステータスアイコンは常に、そのマシンの状態を示します。
セッション中を含め、どこからでも Option+R / Alt+R を使ってエージェントと表示中の会話を更新できます。未開封のプロジェクトにあるエージェントも検出されます。個別の検出用ショートカットはありません。サイドバーにフォーカスがあるとき、r キーを押すと選択中の環境が更新されます。
保存済みの会話を選択して x / X を押すと、そのハーネスから削除できます。ネイティブの削除処理はバックグラウンドで実行され、行はすぐに消えます。削除に失敗すると行が復元され、エラーが表示されます。これはターミナルの接続を解除するだけではなく、保存済みの会話を削除します。下書きの New Thread ペインはそのまま閉じます。また、[S] シェルの行では、これまでどおりセッション終了の操作を使用できます。
アカウントや VM の履歴を定期的にポーリングすることはありません。Codex と OpenCode のタイトルおよびアクティビティの変更は、既存のネイティブクライアント接続から取得されます。アクティブな SSH ハーネスペインからの出力をきっかけに、別の VM 接続を開くことなく、Railway に保存されたセッションレポートをまとめて読み込みます。アイドル状態のサイドバーが履歴を自動更新することはありません。ほかの場所で行われた変更は、次に明示的に更新したときに表示されます。
Claude と Grok の履歴は、Railway のランチャー以外から開始された会話も含め、SSH 経由で VM 上から直接検出されます。Claude では、履歴が初めて検出されたときに VM 上へ自動的にキャッシュされる、固定バージョンの公式 Agent SDK を使用します。Grok では、保存された summary.json のメタデータを使用します。検出では CLAUDE_CONFIG_DIR と GROK_HOME が尊重され、非表示のサブエージェントと空の起動レコードは除外されます。一時的な検出エラーが発生しても、読み込み済みの行は保持されます。Codex と OpenCode も VM 内のメタデータインデックスを公開するため、バックエンド接続をローカルに保存していなくても履歴を利用できます。以前の CLI リリースで opencode2 として保存された OpenCode の履歴は、OpenCode として表示されます。
Claude または Grok のスレッドを選択すると、利用可能な場合は検証済みの実行中ターミナルに再接続します。利用できない場合は、記録されたプロジェクトと設定ディレクトリからネイティブ UI を再開します。Claude のバックグラウンドジョブでは claude attach を使用します。ライブメタデータとフックによってスレッドのステータスが更新され、ネイティブペインが対応する会話 ID に関連付けられます。クラウド VM 上で Grok を起動または再開すると、--trust --always-approve を使用して、フォルダの信頼確認とツールの承認プロンプトを省略します。SSH の自動起動にも、次回の railway code プロビジョニング後に同じフラグが適用されます。ローカルの設定は変更されません。ネイティブの Codex および OpenCode クライアントの操作は、ペインごとに認証されたブリッジを通じて、ペインの正確な会話 ID を更新します。
履歴は保存された VM に属します。休止中のエージェントのスレッドを開く前に、エージェントを起動してください。
SSH シェルと会話の再開
railway ca ssh my-box # open a login shell
railway ca ssh my-box --session # attach to or start a durable session
railway ca ssh my-box --session name # attach to a named session
railway ca ssh my-box --resume # resume the latest Claude conversation
通常の SSH 接続では、ハーネスの自動起動を経由しません。ターミナルの終了後に永続セッションを開く際、対話型ユーザーは最近の Claude 会話を選択できます。CA フレームでは、Option+O / Alt+O で選択中の VM のシェルを開き、終了するとフレームに戻ります。サイドバーの c アクションでは、シェルコマンドをコピーできます。
保存済み接続設定を取得する
railway code get-config # most recently saved connection
railway code get-config my-box # a specific agent by name
railway code get-config codex-railg-3ed # generated names work too
railway code get-config <agent-id> # use an ID if names are ambiguous
railway code get-config my-box --json
Codex のターミナル設定、connect、desktop-only(railway ca desktop --codex エイリアスを含む)では、検証済みのバックエンド接続と Desktop の設定結果が保存されます。OpenCode の設定と再接続でもサーバーの詳細が保存されます。通常のクラウドターミナルの起動では、SSH の詳細が保存されます。
get-config はログイン、ネットワークアクセス、VM の起動、クライアントの起動、Desktop の設定適用を行わず、ローカルのスナップショットを使用して、どのディレクトリからでも実行できます。人が読みやすい形式の出力には、作成時や再接続時と同じ簡潔な結果パネルが使われます。
--json には、保存済みのエージェント/SSH メタデータと、codex または opencode のハーネス固有オブジェクトが含まれます。これらには認証情報と Desktop のステータスも含まれます。これは保存済みの詳細であり、現在のヘルスチェックではありません。最新の情報に更新するには、設定または接続を再実行してください。
Railway は、エージェントごとの最新スナップショットを ~/.railway/code-configs.json に保持し、既存の CLI バージョンとの互換性のために ~/.railway/last-code-config.json への書き込みも続けます。アーカイブを初めて書き込む際には、既存の最新スナップショットが保持されます。名前による検索には、このコンピューターで以前に保存した接続が必要です。不明な名前を指定するとエラーが表示され、名前が重複している場合は ID が一覧表示されます。ファイルはプライベートな状態で、ロックのもとでアトミックに更新されます。railway logout を実行すると、保存済み設定ファイルが両方とも削除されます。
デスクトップアプリでのクラウドエージェント
Claude Code Desktop、Codex、または OpenCode Desktop 用にクラウドエージェントを準備します。
railway ca desktop --claude
railway ca desktop --codex
railway ca desktop --opencode --agent my-box
railway ca desktop --opencode --new
Codex だけを選択した場合、railway ca desktop --codex は railway code --codex desktop-only の互換性エイリアスです。同じバックエンドの起動と Desktop へのインポートフローを使用し、--agent、--new、--dir、プロジェクト/環境、および SSH のエイリアス/設定/検証オプションを引き継ぎます。既存の --dry-run、--remove、複数アプリの設定コマンドも引き続き使用できます。
アプリのフラグを組み合わせることで、同じエージェントを複数のアプリ用に準備できます。設定では、利用可能なローカルのサインイン情報を引き継ぎ、スキル/MCP の同期設定を適用し、エージェントの SSH 設定を書き込みます。--dry-run は、エージェントの作成や起動、接続の開始を行わずに、ローカルファイルのプレビューを表示します。既存のエージェントは再利用され、必要に応じて起動されます。対象環境にエージェントが存在しない場合は、新しいエージェントが作成されます。--new は、複数のアプリフラグを組み合わせている場合も含め、常に新しいエージェントを作成します。--agent または --remove とは組み合わせられません。
Codex の設定では、Codex Desktop のバージョン 1 のアプリ設定を使用して SSH ホストと名前付きリモートプロジェクトを登録します。これはすべてバックグラウンドで行われます。アプリを起動したり、アクティブにしたりすることはありません。Codex Desktop は次回の起動時に設定をインポートします。既存の接続と再試行/タイムアウトの設定は保持されます。設定が変更された場合は、config.json.railway-backup にバックアップされます。--dry-run はマージ後の設定をプレビューします。--remove は SSH ブロックと、そのエイリアスのインポート宣言を削除します。Codex のインポート機能では接続やプロジェクトが削除されないため、すでにインポート済みの接続とプロジェクトは Codex 内で削除してください。
OpenCode Desktop は、エージェントがすでに持つ HTTPS アドレスに直接接続します。CLI は、設定されたコードポート(デフォルトは 4096、レガシー接続では 8080)で、パスワード保護された opencode serve をバックグラウンドで起動し、公開エンドポイントを確認してから、URL、ユーザー名、パスワード、デフォルトサーバー、リモートプロジェクトを Desktop の設定に保存します。Desktop との互換性はリリースチャンネルとは独立して、バンドルされたクライアントのバージョンに基づいて判定されます。互換性がある場合は、安定版の OpenCode(ai.opencode.desktop)が優先されます。JSON 形式のサーバー設定と SQLite のレンダラー状態に対応しています。下書きのみのデータベースであっても、設定の保存先は変わりません。
サーバーはイメージ公式の OpenCode V2 opencode を実行します。CLI がエージェント上で OpenCode をインストールまたはアップグレードすることはありません。opencode が 1.x である古いイメージ、または保存されたサーバーが最後に実行したリリースより古いイメージは拒否され、railway code --opencode --new で新しいエージェントを作成するようメッセージが表示されます。ローカルターミナルクライアントはサーバーに記録されたリリースに従い、必要に応じて ~/.railway/runtimes/opencode-client/<version>/ の下にインストールします。
ターミナルセッションには railway ca --opencode を使用します。新規セッションのピッカーには OpenCode オプションが 1 つ表示されます。Shift+Tab でハーネスを切り替えられます。
セットアップでは接続の詳細と、更新された設定を読み込むために OpenCode Desktop の再起動が必要になる場合があるという注意も表示されます。
プライベートな .railway-backup ファイルは以前の設定とサーバー状態を保持します。
セットアップ後にターミナルを閉じてもかまいません。実行し続ける必要のあるローカルトンネルはありません。
Cmd+B (Windows/Linux では Ctrl+B) を押して Home を開きます。Projects の下で
Railway: <agent-name> と /app (または指定した --dir) を見つけ、そのプロジェクトの
メニュー → New session を使用します。デフォルトサーバーを設定しても
既存のチャットは移動しません。OpenCode は各プロバイダーの有効なアカウントをローカルの V2 認証情報データベース (~/.local/share/opencode/opencode.db、
または $XDG_DATA_HOME/opencode/) からインポートし、
クラウドエージェントですでに設定済みのアカウントを保持します。ローカルの OpenCode がまだ V1 であるマシンにはコピーするストアがありません。
認証情報は SSH 経由で送信され、一時転送ファイルはインポート後に削除されます。コピーできる
ローカルのサインインがない場合は、リモートサーバーの設定でプロバイダーに接続してください。
OpenCode は利用可能な場合、エージェントのコードエンドポイントを使用します。セットアップは
使用中のサーバーポートを引き継ごうとはしません。他のプロセスを停止するか、新しいエージェントには --new を使用してください。
railway ca desktop --opencode --agent my-box を再実行すると、実行中の
サーバーとその認証情報を再利用するか、スリープ/ウェイクまたは再起動後に再び起動します。
リモートの認証情報とプロセス状態は ~/.railway/desktop/opencode/ の下にプライベートに保存され、起動ログはそこの server.log にあります。
railway ca desktop --opencode --agent my-box --remove は、実行中のエージェント上の管理された
OpenCode プロセスを停止し、共有 SSH ブロックとセットアップによって保存された
Desktop 接続/プロジェクトを削除します。スリープ中のエージェントは起動しません。
エージェントは残ります。railway ca sleep my-box でそのコンピューティング課金を停止します。
コントリビューション
このリポジトリをローカルでセットアップする方法については、CONTRIBUTING.md を参照してください。
フィードバック
フィードバックや提案は Central Station で共有してください。