Phoenix
Console

Guide

Connect your Jibo to jibo.io

Last updated 23 September 2026

What you are about to do

Your Jibo was built to talk to a service that was switched off in 2019. Since then it has been a robot that boots, blinks, and cannot hear you. This guide points it at jibo.io instead, and then lets it update itself the rest of the way.

It happens in two moves. First a small, reversible patch — just enough for the robot to reach the server and be offered an update. Then the robot downloads that update itself, and the new system image carries everything else. You are not hand-editing a dozen files on a live robot; you are opening one door and letting the robot walk through it.

Budget about thirty minutes, most of which is the robot downloading and rebooting while you do something else.

1. Before you start

You need:

  • A Jibo robot that powers on. To run the repoint helper over SSH, it must currently be reachable on your network.
  • A computer on the same network, with a terminal.
  • Your robot's IP address — your router's client list will show it, usually as a name like Aero-Root-Okra-Knit.
  • An account on this site if you want to link the robot to yourself. You may repoint first, but you must create an account, confirm the email link we send, and return to link it later. Check spam/junk if the confirmation message does not arrive.

Do not skip this: the robot will reboot several times and will replace its own system partition. That is normal and it keeps a rollback. But if your Jibo holds photographs or messages you care about, copy them off first — the update preserves your data partition, but "preserves" and "guaranteed" are different words.

Jibo is on its setup screen

First ask whether it has already been pointed at jibo.io. Seeing the setup screen does not answer that question: a stock or factory-reset robot may still be trying to contact the original cloud. If you know it already reaches jibo.io, continue directly to QR setup. If not, or if you are unsure, repoint it first.

This route assumes you already have owner-authorized root SSH access. The public helper needs ssh root@<your-robot-ip> true to work without a password prompt. If an SSH mod started the robot in developer mode, that is okay: the helper sets its next boot to OOBE. It refuses to run if active robot credentials are present, and it does not create a server account or consume a claim code.

curl --fail --remote-name https://jibo.io/robot-ota-repoint.sh
bash ./robot-ota-repoint.sh --robot root@<your-robot-ip> --oobe --dry-run
bash ./robot-ota-repoint.sh --robot root@<your-robot-ip> --oobe --yes

The helper reads the OOBE skill's configured server region automatically; if that config is missing or intentionally customized, supply --region <region> explicitly. Review the dry-run plan before applying it. The helper checks free space on /opt before OTA. A stock robot can have a 300 MB filesystem inside a 10 GB partition; if detected, the plan includes a safe in-place ext4 expansion and verifies at least 2 GB free. This filesystem growth is permanent and is not undone by --revert. The helper also patches the robot's cloud and certificate paths, checks that it remains unprovisioned, and leaves its next boot in OOBE. Do not reboot before repointing if rebooting would close your current SSH access. Once it reports success, reboot and use normal QR setup. If this Jibo was paired with your account before being reset, Phoenix reconnects it to its existing loop automatically and preserves that loop's people and history. A genuinely new Jibo gets a new loop. Existing Wi-Fi may make the Wi-Fi portion of setup shorter; QR account pairing is still required.

Do not use the one-time migration claim code on this path. That code proves possession with existing robot credentials, which an unprovisioned robot does not have.

2. Stage 1 — prepare and repoint an already-set-up Jibo

This path is only for a Jibo that was set up before, is not on its setup screen, and still has robot credentials. It starts after you have installed and verified owner-authorized root SSH access from a computer on the same network. This site does not bypass that prerequisite.

The helper deliberately uses a non-interactive root SSH key. Before creating a private pairing code, confirm ssh root@<your-robot-ip> true succeeds without a password prompt. The migration helper does not install or bypass that local access.

First download the public helper and review its plan. This dry run does not change the robot:

curl --fail --remote-name https://jibo.io/robot-ota-repoint.sh
bash ./robot-ota-repoint.sh --robot root@<your-robot-ip> --dry-run

The helper fetches its fixed support files over HTTPS and verifies their SHA-256 hashes before it connects to the robot. Read the plan. It should name only the Jibo client settings, its certificate trust, the hub setting, and an unclaimed server registration.

When you are satisfied, run the same command without --dry-run and answer the confirmation prompt:

bash ./robot-ota-repoint.sh --robot root@<your-robot-ip>

It backs up each file it changes, repoints the robot at the public jibo.io service, and registers its existing robot credentials as an unclaimed bootstrap. That lets the robot reach the update service, but it does not give any web account ownership of the robot. Keep the downloaded helper: you will run it one more time after you sign in.

3. Stage 2 — link it to your account

Repointing proves that the robot can reach jibo.io. Account ownership is a separate, deliberate step so nobody can attach a robot to an account they do not control.

  1. Create or sign in to your account.
  2. Open Robots → Add a Jibo, answer the cloud-target question, then select Already set up / has credentials.
  3. Select Create migration command. The console shows a one-use, 15-minute code already inserted into a command.
  4. Run that command from the same computer. It repeats the safe repoint checks and uses the robot's existing credentials to link it to the signed-in account.

Do not share that code. It is stored by the server only as a hash, expires after 15 minutes, and is consumed only after the robot credential proof and account link both succeed. The claim keeps the robot identity and loop ID; it does not import an old cloud account, people, passwords, sessions, or tokens.

Starting signed out is fine. The Stage 1 command has no claim code and is intentionally safe to run before an account exists. After you create an account, generate a fresh code in the console and run its prefilled command to finish the ownership link.

4. Stage 3 — take the update

If you used the setup-screen path, complete QR pairing first; OOBE may offer its update during setup. The voice-command steps below apply after Jibo finishes setup.

USB-flashed Jibo with preserved /var but no BE skill? It can already be authenticated and linked to your account, but it cannot run the voice-command updater. After Stage 2 reports that the robot was claimed, use the downloaded helper from your SSH-capable computer instead:

bash ./robot-ota-repoint.sh --robot root@<your-robot-ip> --ota-only --dry-run
bash ./robot-ota-repoint.sh --robot root@<your-robot-ip> --ota-only --yes

This uses Jibo's built-in system-manager, not BE or OOBE. It checks the published update plan, downloads and verifies the OS, services, OOBE-skill, and BE packages, then starts the normal rebooting installer. Do not erase the robot's credentials or unplug it during OTA.

If BE is already installed, the usual on-robot path also works:

  1. Say "Hey Jibo, check for updates", or tap through to Settings → Check for updates.
  2. It will find one, and start downloading. This is a large download — a few hundred megabytes — so give it time.
  3. It will back up, install, and reboot itself. Do not unplug it during this.

The image it installs is where the real work lives. It already contains the corrected certificate trust, a networking fix without which the robot cannot download anything over HTTPS at all, correct file ownership and permissions, and a compatibility shim that lets its notification service speak to a modern web server. None of that is something you should have to do by hand, which is exactly why it is baked in.

5. Stage 4 — check it worked

Three things tell you it is done:

  • It answers. Say "Hey Jibo, what time is it?" and it should reply.
  • The console sees it. Your robot appears in the console and reports the new version.
  • No more updates. Ask it to check again; it should say it is up to date.

6. When something goes wrong

It says there are no updates available

If you used the already-set-up path while signed out, create an account and complete Stage 2 first. Otherwise, rerun the helper with --dry-run to inspect its plan. Adding --verify to an apply command rechecks the robot's TLS connection after applying any missing patches; it is not a read-only check.

The download fails immediately

Certificate trust is a common cause. Rerun the current helper with --verify and its normal path flags. This reapplies the patches idempotently and asks the robot to validate TLS to jibo.io. Do not disable certificate verification.

“Updating operating system” restarts every few seconds

The robot may be rejecting the download before making a network request because /opt is too small. A stock 13.0.0 filesystem can be only 300 MB despite a much larger partition. The current setup-screen helper checks for and expands this layout before pairing. If you already paired, do not delete the robot or erase its credentials: restore sufficient /opt space, return it to OOBE, then scan a fresh QR while signed in to the same account. Phoenix will reuse its existing loop. Contact the operator if you cannot regain SSH access.

It updated, but does not respond to its wake word

Give it a full two minutes after the final reboot — the behaviour engine starts last. If it is still silent, check the console: if the robot is not listed, it has not adopted.

It will not boot at all

The robot keeps the previous system on a second partition and rolls back automatically after several failed boots. Leave it powered for ten minutes and let it fall back on its own before intervening.

7. Going back

The helper keeps backups of the files it changes, and the update keeps a previous system partition. The command below restores only the original endpoint configuration; it does not undo the client, certificate, or hub patches. A complete return to a stock image requires restoring a known-good robot image or backup.

bash ./robot-ota-repoint.sh --robot root@<your-robot-ip> --revert

If the robot is still unprovisioned, add --oobe to that command. Do not try to reverse a successful OTA by editing individual files; use its recovery path.

8. Questions

Will this brick my robot?

It is unlikely but not impossible — any firmware update carries risk. The design mitigates it: stage 1 is small and reversible, the update is the robot's own mechanism rather than something forced on it, and there is an automatic rollback. It is still your hardware and your decision.

Do I have to use jibo.io?

No. Phoenix is open source, so you can run an instance at home. This public guide and its downloadable helper are specific to jibo.io; use the operator documentation for the private CA or DNS configuration of a self-hosted instance.

What does jibo.io see?

Everything your robot sends, because it has to pass through the server to work. That is stated plainly in Privacy. If it is not a trade you want to make, self-host.

Is this legal?

This is a clean-room reimplementation that talks to hardware people already own. It ships no code belonging to anyone else. It is not affiliated with or endorsed by Jibo, Inc. or any successor.

Something is broken and this page did not help

Open an issue on GitHub with what you ran and what it printed.