How I used Claude and an open-source launcher to customise my TCL TV, add a Jarvis dashboard, and build a reusable Android TV harness.
I hacked my TV. It started with a very ordinary irritation: the home screen of my TCL, running Google TV, was dominated by a sponsored placement and rows of recommendations. I wanted somewhere simpler to open the apps I actually watch.
On Sunday, 18 October, I used Claude to customize that setup. The result was a clean launcher with my streaming apps, a clock, and the controls I need. Then I added the part that made it personal: a Jarvis button.
The starting point was Gathin’s open-source tv-vibehack project. Credit matters here: I built on an existing launcher. My addition was connecting the experience to my own assistant dashboard and developing a public harness around the TV workflow.
The button opens a view of my Codex sessions and important emails. Another button takes me back to the normal TV interface. The same screen can help me glance at what is running, then get out of the way when I want to watch something.
The change is easier to see than to explain
The original screen was organised around discovery: a large sponsored panel, suggested shows and apps. That may suit someone browsing for something new. My use was more specific. I usually know which app I want, so those extra layers were friction between switching on the TV and doing the thing I came for.
The custom launcher puts YouTube, Netflix, JioHotstar, Prime Video, SonyLIV and Spotify in a simple dock. Above them are the time, date, and buttons for Jarvis, Inputs, Wi-Fi and Settings. I can see the things I came to use without a large sponsored panel competing for attention.
Here, “hacking my TV” means customizing the software interface on a television I own. The existing hardware supplies the screen, remote and Android platform. I get to decide what the home screen is for.
What I cared about first was the experience: a direct route to familiar apps and a layout I could make my own. The before-and-after photos capture that change. Measuring speed or memory would be a separate exercise.
Then I put Jarvis on the screen
A cleaner launcher was useful. The dashboard gave the television another job. Instead of opening my laptop just to check a task, I could look at the TV and see the recent Codex sessions, their working or idle states, and a small panel of important emails.
That is the part I wanted to show during the workshop. A television is a large display that already lives in a shared space. It does not have to show the same kind of information all day. A glanceable status view can be useful there, provided returning to normal TV remains straightforward.
The agent work still happens on my existing computers and systems; the TV gives me another place to see it. At the point shown in the session, this was a monitoring view. Sending new tasks from the television had not been configured, and a separate mobile-control idea was still work in progress.
I like starting with a useful capability this small. I could see the work and return to the apps. Once that interaction feels right, it becomes easier to decide whether another control would actually help.
There are three different pieces here
The photos make the whole setup look like one product. Underneath, it is useful to separate three responsibilities. Each has a different job, and each can be changed without pretending the others come for free.
The launcher. The Android interface: app shortcuts, navigation, focus, settings and an entry point to another view. The personal dashboard. The view of my sessions and email. It depends on my own data connections and access decisions. The TV-operation harness. The surrounding process for inspecting a device, preparing a change, checking the result and recovering when the requested behavior does not happen.
I published the Android TV Harness so the reusable TV workflow has a home of its own. The repository contains the launcher and device-operation harness. My personal Jarvis dashboard, its configuration and its data connections are not included. The public workspace destination is blank by default; a reader can configure their own later.
The photographs show my personal setup. They should not be read as proof that the public package is the exact build installed on that physical TV. The packaged harness has its own verification record, including an Android TV emulator trial and its limitations.
The useful part is the workflow around the command
An AI coding tool can help inspect a project, modify code and operate development tools. Once it can change a real device, the job needs more structure than “make this look better.” It needs to know which device, what is allowed to change, what success means and how to recover.
That is why I connect this project to vertical harness engineering. A harness is the surrounding system that makes model-driven work usable: context, tools, permissions, state and feedback. A vertical harness specialises those choices for a particular job. Here, the job is a controlled TV-interface change.
For this workflow, the sequence is inventory, plan, review, apply, verify and restore when needed. Inventory establishes the target and current state. A saved plan turns a vague request into an inspectable change. Review gives the owner a chance to understand that change before it reaches the device.
Apply is only one stage. Verification asks whether the user-visible outcome actually happened. Recovery provides a path back if it did not. These steps are useful even when the code itself is small; the importance comes from what the code can affect.
A file describing those rules is a specification. The runtime has to enforce them. The public TV harness checks details such as the target identity, saved plan, expiry, state drift and APK hash. A local plan identifier helps bind an operation to a particular plan; it is not a substitute for authenticating a human user.
A successful command did not mean a successful Home button
The public verification record includes a particularly useful failure. In an Android TV 14 emulator, the app could be installed and launched directly. Android accepted the Home-selection operation, yet the stock launcher retained priority.
The command response looked encouraging. The behavior was wrong. Pressing Home still did not establish the intended result. The harness detected the mismatch and reported failed_rolled_back instead of calling the change complete.
That is the engineering lesson I would carry into another project. A file saved successfully may contain the wrong data. An API response may precede a failed downstream job. An installed app may not handle the button you expected. Check the outcome at the level the user experiences it.
For a TV, that means checking direct launch, directional focus, Back, Home and returning from a streaming app as distinct behaviors. Vendor-specific inputs and remotes also need their own checks. The emulator evidence does not establish compatibility with every physical television.
How to explore the public version
Start by identifying the television’s operating system. The project targets Android and Google TV. A TCL label alone does not establish that: a TCL running Roku OS is a different platform. Samsung Tizen, LG webOS and Fire TV are outside the project’s stated support.
You can inspect the repository and run its simulated-device tests before connecting hardware. The full build uses Python 3.10+, native Android platform-tools, JDK 17 and Android SDK API 34 with build-tools 34.0.0. Follow the current README for the setup on your computer.
Start locally, before connecting a television
git clone https://github.com/harshith-vaddiparthy/Android-TV-Harness.git
cd Android-TV-Harness
python3 -m unittest discover -s tests -v
python3 -m harness doctor
These tests do not operate your TV. The doctor command reports prerequisite readiness. The launcher/build-harness.sh script builds, tests and lints the Android application locally. Keep those local checks separate from a decision to install or change something on a device.
For an actual trial, use a device you own or have permission to manage and follow the pairing and recovery runbook. Deliberately enable the supported debugging mode, read the pairing instructions on that device, and identify the exact serial shown by adb devices. Pairing and connection ports can differ and change.
Sharing a Wi-Fi network is not authorization and does not guarantee control. The device must expose the supported interface and accept the connection. The public runtime does not scan the network or automatically choose a television for you.
Once connected, inspect the inventory and proposed plan before applying a change. Understand the restore path while the stock launcher is still available. Keep access codes and private configuration out of shared prompts and repositories. If you add your own dashboard, decide deliberately what a person standing in front of that screen should be able to see.
The brief I would give the next project
The most transferable part of this exercise is the brief. Make the desired interface concrete, identify the existing foundation, and define the check before the tool begins making changes. This is a fresh example prompt, not an export of my private assistant instructions.
A bounded starting prompt
Help me customise the launcher on my own Android/Google TV.
First inspect this public repository and explain its workflow.
Start with local tests and prerequisite checks.
Inventory only the exact device I identify and authorise.
Prepare a plan showing what changes and how to restore it.
Wait for my review before applying a device change.
Keep the stock launcher available.
Check direct launch, remote navigation, Back and Home separately.
Report mismatches rather than treating an accepted command as success.
That prompt does not make an arbitrary tool safe by itself. It gives the work a clear contract. The value comes from pairing the contract with software that actually checks the target, limits the operation and verifies the result.
The screen should serve the job
This began as a home-screen annoyance and turned into a useful way to look at my own work. I can open the apps I watch, glance at a dashboard when I want it, and switch back. That is a modest change to the hardware’s role, but a meaningful change to the interface I use.
I would apply the same thinking to another device or internal tool: choose one recurring job, start from a capable existing foundation, add only the context and controls that job needs, and verify the visible result. The impressive part is not how many things an AI tool can be asked to do. It is getting a particular thing to work in a way its owner understands.
I write about builds like this and the practical decisions behind them in The H Letter. If you want the broader framework, the vertical harness guide and interactive workshop develop the method beyond this TV example.
Subscribe free to Harshith's Newsletter to read every article in the interactive edition.
Harshith Vaddiparthy works with founders, operators, and teams on practical AI products, workflows, advisory, training, and mentorship. This no-JavaScript version preserves the page's core information and navigation.