Google Colab CLI documents a terminal workflow for executing local code on a Colab runtime. The local repository checks established installation and build success, followed by 200 collection/setup errors. They did not establish that an unattended cloud job completes safely.
Local scripts execute on a remote Colab kernel
The README documents execution of Python scripts, notebooks and code sent through standard input. It explains that colab exec -f file.py reads the script locally and transmits its content to the remote kernel. Separate upload and download commands manage remote files.
Sending a script does not establish that its local data files exist on the runtime. Identify the inputs to transfer and the outputs to retrieve before starting a job.
The documented colab run workflow provisions a fresh runtime, executes a local script and tears down the VM. The --keep option preserves the VM for inspection, while manually managed sessions have a stop command. These are documented capabilities; provisioning, execution and cleanup against a real Colab account were not verified in the supplied sandbox run.
What happened when we ran it
Google Colab CLI installed in 25 seconds and built in 1 second in the sandbox. Tests exited 1 after 5 seconds, with zero passed, zero failed and 200 collection/setup errors. The zeros do not describe a successful suite: the errors prevented a useful test result.
The run used commit d2d9779 on November 8, 2026. It recorded 81 dependencies occupying 251 MB, with 93 files, approximately 15,907 source lines and a 1.9 MB checkout. Pip-audit reported zero known vulnerabilities, with 80 packages scanned and one skipped. That audit result does not establish the security of cloud credentials or remote execution.
The log tail lists runtime tests covering kernel clients, execution and streaming timeouts. Its stopping message says 200 failures, while pytest's summary reports 200 errors in 2.42 seconds. The recorded outer test step took 5 seconds. The supplied tail contains no root exception, so it cannot establish a package or environment cause. Test names alone do not establish which runtime behavior is broken.
The configured sandbox had 3 CPUs, 8 GB RAM and image ghcr.io/astral-sh/uv:python3.12-bookworm. The image label does not establish actual runtime versions. The checkout scan found a tests directory, zero CI workflow files and no Dockerfile. Those observations do not establish whether testing occurs elsewhere. No authenticated Colab workload was measured.
Choose the authentication provider explicitly
The README lists ADC as the default provider. The authentication design guide labels OAuth2 the default. Select a provider explicitly during evaluation rather than relying on either stated default.
The guide describes OAuth2 authorization through a URL and a code that the user copies back into the terminal. It describes refresh-token storage in the OS keyring and warns that inaccessible or locked keyrings can trigger authorization again. Failed token persistence can mean another prompt on every command. A remote host therefore still needs a workable authorization process before it can run unattended.
ADC uses Application Default Credentials and is documented for environments that already have Google credentials. Backend authentication is separate from colab auth, which authenticates the VM for Google Cloud services. Drive mounting is another operation. Successful installation does not verify any of these authorizations.
A reported disconnect can leave execution running
In the supplied issue-and-PR record, the contributor who filed issue #220 reports that a kernel WebSocket disconnect can end colab exec monitoring while remote execution continues. The report warns that rerunning the command risks submitting the work twice. It also says colab run shares the execution path and normally releases its VM when it exits.
These are contributor-reported observations, not independently reproduced findings from the sandbox. The supplied evidence does not establish whether the tested commit d2d9779 is affected.
The contributor proposes bounded reconnection on the same kernel, Jupyter session and execution request, without resubmitting code. Proposed fix #221 is open in the supplied record, with merged_at:null. Its author's reported validation does not establish that the change is merged or available in the tested checkout.
Before unattended use, include a controlled connection interruption in the acceptance check. Verify whether the original execution continues, how completion is determined and how cleanup behaves. Confirm that recovery does not submit the same job again. Treat a lost monitor as an uncertain execution state until the original job's status is established.
Platform and hardware limits matter
The README supports Linux and macOS only; Windows is not supported. The contributor's Windows test claims in proposed fix #221 do not change that documented support policy or establish compatibility for the tested checkout.
According to the usage notes, high-memory requests require Colab Pro or Pro+ entitlement for supported accelerators. L4 and TPU runtimes ignore the flag because they offer one machine shape. The local sandbox does not establish what hardware an account will receive or what a cloud job will cost.
The README also documents TTY requirements for interactive REPL and console use. Choose an execution mode suited to the intended host. Start with a small disposable workload, verify its output locally and confirm that the runtime is released. This is a recommended acceptance check, not a cloud cycle completed during this review.
Alternatives depend on the workflow
Colab MCP connects a local agent to a Colab session in the browser. Its README requires a locally running client with notifications/tools/list_changed support. Evaluate it when agent interaction with the browser notebook is the requirement.
SkyPilot documents an interface spanning reserved GPUs, Kubernetes clusters, Slurm clusters and clouds. Its README makes it a candidate when infrastructure requirements extend beyond Colab. Setup effort, execution reliability and cost were not compared between these projects.
The supplied repository metadata records Colab CLI's last push as November 6, 2026, and the issue-and-PR record contains activity on November 7. The supplied evidence does not establish a latest GitHub release. Recent activity does not resolve the sandbox errors or establish support capacity.
Documentation receives 3/5 on this review's editorial rubric: 1 means essential task instructions are missing, 3 means a documented task path has material gaps or contradictions, and 5 means coverage has been independently checked across documented routes. The command index supplies a task path, but the contradictory authentication defaults leave an automation question unresolved. This is a documentation judgment, not a compatibility or reliability measurement.
Setup ease, community and maturity remain unassessed. Before assigning unattended work, verify a complete create-execute-retrieve-stop cycle on the intended host, including connection loss and prevention of duplicate submission.