“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 Link to heading
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 Link to heading
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 Link to heading
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 Link to heading
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 Link to heading
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 Link to heading
- Head Units are just Weird Tablets: They have quirks (like Slave-only Bluetooth), but they are standard Android under the hood.
adb rootis 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.