ericxliu-me/content/posts/vibe-coding-from-the-jeep.md

title, date, draft

title	date	draft
Hacking a Chinese Car Stereo to fulfill my Knight Rider dreams	2026-01-21	false

"Vibe coding" has become my latest obsession. It's that flow state where the tools disappear, and you're just manipulating logic at the speed of thought. Usually, this happens in a high-end IDE like Antigravity. But lately, I've been trying to answer a childhood dream.

Growing up in China before the internet age, my window to the outside world was CCTV-6. Along with Baywatch, one of the first American TV shows I ever watched was Knight Rider. I don't remember the exact plot lines, but the core concept stuck with me forever: KITT. A car that could talk, think, and do things for you.

Decades later, I'm sitting in my Jeep, wondering: Can I build my own KITT? Can I take the vibe on the road?

I already updated the head unit in my Jeep to an aftermarket unit. It features a K706 (UIS7862S) chipset with an 8-core CPU and 8GB of RAM, essentially making it a reasonably powerful Android tablet hardwired into the dashboard.

The Objective

Turn this car accessory into a legitimate dev environment. I wanted a physical keyboard, a real terminal, and access to my AI coding assistants. I wanted to push code while parked on a trail.

The Hardware Blocker: Getting Input

The first hurdle was mundane but blocking: My Bluetooth keyboard wouldn't pair. The head unit could see other devices, but refused to connect to my keyboard.

Attempt 1: The USB Dongle Bypass

My first instinct was to blame the cheap Chinese head unit hardware. I grabbed a spare TP-Link USB Bluetooth dongle and plugged it in, hoping to bypass the internal stack entirely.

The device showed up in lsusb, but it remained inert. A quick check of the kernel config via zcat /proc/config.gz revealed the bad news:

# CONFIG_BT is not set

The kernel was compiled without generic Bluetooth driver support (btusb). Even with root access, I couldn't load the drivers because they simply didn't exist in the firmware. I was stuck with the internal hardware.

Attempt 2: The "Dual Bluetooth" Fix

Forced back to the built-in Bluetooth, I tried to diagnose why it was ignoring my keyboard. Standard debugging tools painted a grim picture:

❯ hciconfig -a
# (Empty output - no standard HCI interface found)

❯ ps -A | grep -iE "goc|ivt|syu"
u0_a50 3456 ... com.goc.sdk  # Accessing the proprietary BT chip

The diagnosis was clear: The internal Bluetooth chip is acting in Slave Mode (Client), managed by a proprietary com.goc.sdk service instead of the standard Android Bluetooth stack. It's designed to be a speaker for your phone, not to host a keyboard.

The Fix: Hidden deep in the Factory Settings (password 8888), there's a toggle called "Dual Bluetooth". Enabling this flips the proprietary stack to expose a standard Host interface. Enable that, and suddenly my mechanical keyboard connected instantly.

The Software: Termux + Claude

With input sorted, the software setup was surprisingly straightforward. Termux was the obvious choice for a terminal.

I discovered that Claude Code works on Termux with zero hassle.

The setup was shockingly simple:

pkg install nodejs git ripgrep
npm install -g @anthropic-ai/claude-code

Authentication via claude login worked out of the box. Now, I have a fully capable coding agent running directly on my dashboard. I can pull a repo, ask Claude to refactor a module, and push the changes—all without opening a laptop.

Key Insights

• Head Units are just Weird Tablets: They have quirks (like Slave-only Bluetooth), but they are standard Android under the hood. adb root is your best friend for diagnosing them.
• Check the Kernel Config: Before buying hardware peripherals for embedded Android devices, always check /proc/config.gz. If the support isn't compiled in, you're dead in the water.
• The Vibe is Portable: With tools like Termux and Claude Code, the "dev environment" is no longer a heavy laptop. It's anywhere you have a terminal.

References

1. Reddit: Claude Code on Termux