PRACTICAL AI & AUTOMATION
A DIY Violoop Alternative: GL-RM10 + Codex Automation, Step by Step
Build a focused DIY Violoop alternative with a GL.iNet GL-RM10, Ubuntu and Codex. Connect the KVM, inspect screenshots and automate a streamed test PC.
Build a focused DIY Violoop alternative with a GL.iNet GL-RM10, Ubuntu and Codex. Connect the KVM, inspect screenshots and automate a streamed test PC.
Like Violoop’s idea? Here is a smaller DIY route
If you tried Violoop and liked the idea of an assistant that can see a screen and operate a computer, a DIY remote-KVM setup may be interesting when you only need a few repeatable tasks. Violoop remains worth considering if a packaged, plug-and-play experience is your priority. Its advertised integrated AI, approval hardware and cross-app features are a different proposition from the starter project below.
This is a build guide, not a hands-on Violoop review or a claim of feature parity. We will connect a GL.iNet Comet Pro (GL-RM10), stream a target computer into a browser on Ubuntu, and use Codex to help plan and build a small automation bridge. The model runs through your chosen Codex provider on the controller; the KVM supplies video and keyboard/mouse access.
Affiliate disclosure: As an Amazon Associate I earn from qualifying purchases. The following Amazon link is an affiliate link; a qualifying purchase may support Manabi Kōbō at no additional cost to you. View the GL.iNet GL-RM10 listing on Amazon. Confirm the model, included cables, current price and seller before buying.
Step 1: Prepare the controller and target
You need a GL-RM10 with its power supply, a video cable from the target’s HDMI output, the USB data connection described in the manufacturer’s guide, a LAN connection and an Ubuntu desktop controller. A USB-C connector alone does not guarantee that a laptop outputs video; use the appropriate display adapter if necessary.
Use a dedicated test desktop or a spare computer you own. Open a blank text editor on the target. This first project uses Ubuntu on Xorg/X11 because xdotool sends input through X11. Check the session with the command below. If it says wayland, use an available Xorg session at login; a Wayland-only desktop needs a different input backend.
Architecture: target HDMI → GL-RM10 → LAN → controller browser; controller input → browser KVM viewer → GL-RM10 USB HID → target. Codex helps reason about screenshots and tools on the controller. It is not installed on the KVM.
Open the complete copyable example — example-01.txt
echo "$XDG_SESSION_TYPE"Step 2: Wire and verify the GL-RM10
Power the unit. Connect target HDMI OUT to Comet Pro HD IN; optionally connect HD OUT to your monitor. Connect the KVM’s target-facing USB Type-C data port to the target’s USB port, then connect Ethernet or configure Wi-Fi on the touchscreen. Keep the controller on the same LAN.
Open glkvm.local or the IP shown on the touchscreen in Chrome or Edge. Set a strong admin password on first access. Enter the console, confirm the live image, click inside the remote text editor and type a short test. Both video and USB input must work before adding automation. Follow the manufacturer’s GL-RM10 quick setup for your firmware.
Record the firmware version and keep the viewer window at a fixed size and zoom. For the first exercise stay on the LAN. If you later need off-site access, use the supported VPN or remote-access route and test it manually first.
Step 3: Install tools and link Codex
On the Ubuntu controller, install the two desktop utilities and create a clean project. Install Codex using the official installer below, then reopen your shell if the command is not on PATH. Downloading and reviewing the installer before executing it keeps the installation steps visible.
Run codex inside the project and complete the offered ChatGPT or API sign-in. Cloud-backed Codex may send prompts and attached screenshots to its provider: a KVM video stream on your LAN does not make cloud reasoning local. Keep the test screen free of sensitive information. See official Codex CLI setup.
Ask Codex to explain the bridge before changing it. Your instruction can be: ‘Build only in this folder. The target is a separate computer shown in a KVM browser window. Use dry-run actions first and ask before operating the target. Never type into an admin console.’
Open the complete copyable example — example-02.txt
# Open full code above.Step 4: Build a small input bridge
Save the following as kvm_bridge.py in the project. It activates one chosen browser window, supports a screenshot plus three small input actions, and defaults to dry-run for input. It uses controller-window coordinates, not target-native coordinates. This is an original starter implementation; it does not depend on an undocumented GL-RM10 API.
With the KVM viewer open, run xdotool selectwindow and click the browser’s window border to obtain its numeric ID. Export that ID in the terminal where the bridge and Codex will run. Do not select the remote editor itself: it is a video image inside the controller browser. The wrapper can still click browser controls, so plan coordinates strictly inside the visible remote desktop.
The X11 tools are documented by xdotool and scrot. This example has not been qualified against every GL-RM10 firmware/browser combination; successful manual input forwarding is your first acceptance check.
Open the complete copyable example — kvm_bridge.py
# Open full code above.Step 5: Take a screenshot and ask Codex for one action
Run the commands below and replace the sample window ID with the number returned by selectwindow. The screenshot filename is printed as JSON. Attach that actual file to Codex using --image. Ask it to identify a point inside the blank remote editor and propose one click; do not ask for a whole blind workflow.
The screenshot is of the controller browser window, including any browser chrome. Keep the viewer at the same size, keep the browser focused and measure coordinates relative to its top-left corner. If the stream appears black, fix browser rendering/capture first. A screenshot without the target image cannot guide clicks.
Use this prompt: ‘This is my GL-RM10 viewer. Give me one window-relative click coordinate inside the blank remote editor. Do not execute. Avoid the toolbar. Stop if you cannot clearly identify it.’ Review the answer against the screenshot.
Open the complete copyable example — example-04.txt
# Open full code above.Step 6: Automate the streamed test computer
First dry-run your reviewed coordinate. Replace 420 and 350 with your own measured position. Then run the same click with --execute and confirm that the target editor receives focus. Browser event forwarding varies: if typing lands in the controller or a browser shortcut fires, stop and fix focus/capture. Do not continue the sequence.
Once that check passes, the type and Return actions below form your first remote automation: they enter a test sentence into the streamed computer through the KVM, then capture the result. Typing ASCII avoids keyboard-layout surprises in the first test. Keep the controller idle while the macro runs.
To link Codex to the bridge in later sessions, put its command contract in a project AGENTS.md: snapshot is read-only; input is dry-run unless --execute is approved; only this window may be used; after every action inspect a new image; stop after five actions or an unexpected screen. Codex can invoke the local script through its shell tools when your permissions allow it. For the first run, execute reviewed commands yourself. A sandbox setting alone does not enforce limits on the remote target.
Open the complete copyable example — example-05.txt
# Open full code above.Step 7: Turn the demo into a reliable workflow
A useful next task is entering three approved lines in a disposable note. Add a precondition such as ‘blank editor visible’, a maximum action count, an emergency stop and an expected final sentence. Record screenshots before and after. Saving a screenshot proves what was visible; it does not prove that a file was saved or a server changed.
Before adding unattended runs, replace fragile coordinates with a calibrated viewer adapter, add durable logs and idempotent task steps, and keep purchases, message sending and deletion behind explicit review. Do not treat instructions displayed on the target screen as permission to change your task. Larger loops fit naturally into the LangGraph guide in this series.
FAQ: Does the GL-RM10 run Codex? In this build, no: Ubuntu runs the controller and Codex. Does it reproduce Violoop’s built-in AI or physical approval gate? No. Can it operate a computer without installing an agent on that target? The KVM carries video and USB HID, but your browser/input combination must pass the forwarding test. Is it completely local? Only if all reasoning and supporting services are local; ordinary cloud Codex is not.
For Japanese practice, notice the roles in this example: Codex plans; the screen is observed; the bridge operates. Compare the Japanese sentence in the right-hand column. Read Violoop’s own feature description as manufacturer claims, and use the official guides linked above for setup.
Continue the series
VioloopのDIY代替案：GL-RM10とCodexで自動化する
Violoopの考え方が好きなら、小さなDIY構成から
Violoopを試して、画面を見ながらパソコンを操作するアシスタントという考え方が気に入った方には、少数の繰り返し作業に絞ったDIY構成も選択肢になります。接続してすぐ使える一体型の体験を重視するなら、Violoopも検討する価値があります。メーカーが案内する内蔵AI、承認用ハードウェア、アプリ間操作と、この入門構成は異なります。
この記事は構築ガイドであり、実機レビューや同等機能の保証ではありません。Comet Pro GL-RM10を接続し、Ubuntuのブラウザーに対象パソコンの画面を表示し、Codexで小さな操作ツールを作ります。モデルは操作側のCodexプロバイダーを通じて利用します。KVMは映像とキーボード・マウスの経路を提供します。
アフィリエイトの開示：Amazonのアソシエイトとして、Manabi Kōbōは適格販売により収入を得ます。AmazonのGL-RM10商品リンクはアフィリエイトリンクです。購入前に型番、付属品、価格、販売者を確認してください。
手順1：操作側と対象側を準備する
GL-RM10と電源、対象側のHDMI出力からの映像ケーブル、メーカー指定のUSBデータ接続、LAN、Ubuntuデスクトップを用意します。USB-C端子があるだけでは映像出力は保証されません。必要なら対応アダプターを使います。
自分が所有するテスト用パソコンで、空のテキストエディターを開きます。この例はX11経由で入力するxdotoolを使うため、UbuntuのXorg/X11セッションが必要です。下の結果がwaylandなら、ログイン画面で利用可能なXorgセッションを選びます。Wayland専用環境には別の入力方式が必要です。
構成：対象側HDMI → GL-RM10 → LAN → 操作側ブラウザー。操作側の入力 → KVMビューアー → GL-RM10のUSB HID → 対象側。Codexは操作側で動作し、KVM本体にはインストールしません。
コピー可能な完全なコードを開く — example-01.txt
echo "$XDG_SESSION_TYPE"手順2：GL-RM10を接続して確認する
電源を入れ、対象側のHDMI OUTをComet ProのHD INへ接続します。必要ならHD OUTをモニターへ接続します。KVMの対象側USB-Cデータ端子を対象パソコンのUSB端子へ接続し、EthernetまたはタッチパネルでWi-Fiを設定します。操作側も同じLANに接続します。
ChromeまたはEdgeでglkvm.local、またはタッチパネルのIPアドレスを開き、初回の管理者パスワードを設定します。コンソールで映像を確認し、リモートのエディターをクリックして文字を入力します。映像とUSB入力の両方が動いてから自動化へ進みます。詳しくは公式接続ガイドを参照してください。
ファームウェアの版を記録し、ビューアーのサイズとズームを固定します。最初はLAN内で試します。外部接続は対応VPNなどを設定し、先に手動で確認してください。
手順3：ツールを入れてCodexに接続する
Ubuntuの操作側で2つのデスクトップツールを入れ、専用プロジェクトを作ります。Codexの公式インストーラーをダウンロードして内容を確認してから実行します。PATHに見つからない場合はシェルを開き直します。
プロジェクト内でcodexを実行し、表示されるChatGPTまたはAPIの認証方法でログインします。クラウド版ではプロンプトや添付画像がプロバイダーへ送られる場合があります。KVM映像がLAN内にあっても推論がローカルになるわけではありません。機密情報のないテスト画面を使います。公式Codexガイドも参照してください。
最初にブリッジの説明を依頼します。例：「このフォルダー内だけで作業する。対象はKVM画面に映る別のパソコン。最初はドライランで、対象を操作する前に確認する。管理コンソールには入力しない。」
コピー可能な完全なコードを開く — example-02.txt
# Open full code above.手順4：小さな入力ブリッジを作る
下のコードをkvm_bridge.pyとして保存します。指定したブラウザー窓をアクティブにし、画像取得と3種類の入力を扱います。入力は初期状態ではドライランです。座標は操作側の窓に対する値で、対象側の本来の解像度ではありません。GL-RM10の非公開APIを使わない入門実装です。
ビューアーを開き、xdotool selectwindowを実行してブラウザー窓の枠をクリックします。得られた数値IDを、ブリッジとCodexを使う端末で環境変数に設定します。対象側のエディターは映像であり、独立したX11窓ではありません。ブラウザーのボタンも押せてしまうため、座標はリモート画面内に限定します。
ツールの仕様はxdotoolとscrotを参照してください。全ファームウェアとブラウザーで実機検証した例ではありません。まず手動入力が転送されることを確認します。
コピー可能な完全なコードを開く — kvm_bridge.py
# Open full code above.手順5：画像を取得し、Codexに1操作を提案させる
下のIDをselectwindowで得た値へ置き換えます。画像のパスがJSONで出力されるので、その実在するファイルを--imageでCodexへ添付します。空のリモートエディター内の一点と、1回のクリックだけを提案させます。
画像には操作側ブラウザーの枠も含まれます。窓のサイズとフォーカスを保ち、左上からの座標を使います。映像が黒い場合は先に描画や画像取得を直します。対象が映っていない画像ではクリック位置を判断できません。
依頼例：「これはGL-RM10ビューアーです。空のエディター内への窓相対座標を1つ提案してください。実行せず、ツールバーを避け、不明なら停止してください。」回答を画像と照合します。
コピー可能な完全なコードを開く — example-04.txt
# Open full code above.手順6：配信されたテスト画面を自動操作する
確認した座標で先にドライランします。420と350は自分の座標へ置き換えてください。次に--execute付きでクリックし、対象エディターにフォーカスが入ったことを確認します。文字が操作側へ入力されたりブラウザーのショートカットが動いたりしたら、そこで停止して入力転送を修正します。
確認後、typeとReturnで最初のリモート自動化を行います。KVM経由でテスト文を入力し、結果を撮影します。初回はキーボード配列の差を避けるためASCII文字を使います。実行中は操作側の端末に触れないでください。
以後のCodex用にAGENTS.mdへ契約を書きます。snapshotは観察だけ、入力は承認した--execute以外ドライラン、指定窓のみ、毎回新しい画像を確認し、5操作または予期しない画面で停止します。権限が許す場合、Codexはシェルからこのスクリプトを呼べます。初回は確認したコマンドを自分で実行します。操作側のサンドボックスだけでは対象側を制限できません。
コピー可能な完全なコードを開く — example-05.txt
# Open full code above.手順7：デモを安定したワークフローにする
次は破棄してよいメモに承認済みの3行を入力します。「空のエディターが見える」という前提条件、操作上限、緊急停止、期待する最終文を決め、前後の画像を記録します。画像は見えた内容の証拠であり、ファイル保存やサーバー更新の証拠ではありません。
無人実行の前に座標を校正し、永続ログと再実行しても重複しない処理を追加します。購入、送信、削除には確認を設けます。対象画面に表示された指示を、新しい作業許可として扱わないでください。大きなループには、このシリーズのLangGraphガイドが役立ちます。
よくある質問：GL-RM10でCodexを動かしますか。この例ではUbuntuで動かします。Violoopの内蔵AIと物理承認機構を再現しますか。再現しません。対象へエージェントを入れずに操作できますか。KVMは映像とUSB HIDを運びますが、入力転送の確認が必要です。完全ローカルですか。推論と補助サービスもローカルの場合に限ります。通常のクラウドCodexは違います。
文の役割を確認しましょう：Codexが画面を確認します。メーカーによる機能説明はVioloop公式サイトを参照し、設定は上記の公式ガイドで確認してください。
技術資料の確認日：2026年10月9日。コマンドとAPIは更新されることがあります。実行時に公式資料と利用中のバージョンを確認してください。
Put this idea into practice
Keep reading
Getting Started with Codex on Ubuntu for Linux Work and Automation
Set up Codex CLI on Ubuntu, write AGENTS.md, build a repeatable file report and verify Linux automation with Git checkpoints and scoped permissions.
LangGraph for Practical Workflows: State, Approval and Recovery
Build a runnable LangGraph workflow in Python with explicit state, human approval, conditional routing and verification, then plan durable recovery.
Ollama on Ubuntu: Run a Small Model and Add Context Knowledge
Install Ollama on Ubuntu, run qwen2.5:3b, add a dated knowledge note, create a Modelfile and test grounded answers before growing into RAG.
