How to Build Vertical Harnesses: The Car Analogy, a Reusable Folder Template, and Live Builds that Print a Keycap, Replace a TV's Bloatware, and Reach Physical Devices Over SSH and Tailscale

He compares the Codex app (plugins, skills, a visual chat) with the Codex command-line interface, installed with a one-line command from the repo; sign in with the same ChatGPT account or use an API key (he used a personal API key for this demo). His claim: OpenAI ships new skills and plugins in the CLI harness first and the app later, and the whole Codex harness is open source (github.com/openai/codex, 'a lightweight coding agent that runs in your terminal'), so you can build your own harnesses or tune Codex itself, including to reduce token consumption. He checked and does not think Claude Code's harness is open source. Hermes can call the Codex CLI, and his Jarvis controls it in a sandbox because the harness is built for OpenAI's models. Why the CLI over the app: faster feel, /fast mode and model selection, several terminal tabs, and lower memory and heat (the app with three running workflows made his MacBook very hot). The slash commands: /init creates the agents/CLAUDE file and is a command, not a folder. Version quoted as '1.6.16' on screen (as heard); model GPT 6.1. A participant notes the CLI does not load a UI, so fewer turns; he agrees but is not sure which consumes more tokens.

Method: create an empty folder, open it in Codex CLI, and prompt: treat this folder as a template for a vertical harness, add every file needed, start with a task.md, and first show the folder tree including where tasks run, who has access, the model and so on. Codex returns a tree he accepts, then he asks it to rename the folder to vertical-harness and fill it in. The template contains: TASK.md (the purpose and decisions to fill in - the one file you cannot skip), README.md, AGENTS.md, an ignored environment-variables file, configuration (model, access), a domain folder (what the domain is, rules, evidence), workflows (including YAML files that become GitHub Actions and can run on a cadence - every minute, every hour, on task completion), prompts and specialist system prompts, evals (the harness itself checks the job was done in the intended way), operations (monitoring set-up), templates, and decisions and run records. The five he insists on: task, configuration, domain, workflows, evals. YAML is the superset of JSON that is easier to read for configs; the folder structure itself replaces agents as the unit. He pushes it to GitHub as a public repo (harshith-vaddiparthy/Vertical-Harness, 23 files verified) with a README on how to fork it; the next harness is built by giving Codex a use case and telling it to follow this structure. Decision in Q&A: one standalone repository per specialised harness, with the main repo as the template plus an examples directory that links to each; do not push to GitHub mid-build.

He has been 3D printing for about a month (a Bambu Lab A1 combo with four filament slots; filament about 10 USD a reel; the printer does not ship with filament) and says earlier prints without a harness had stringing and chips; a harness can know the nozzle and temperature and reduce this. The steps: choose a model on MakerWorld (the keycap, suggested by Sara), download the 3MF (a 3 MB file with base, cover and key parts and a Bambu P2S profile he does not recognise), then a 'word-vomit' prompt to Codex: confirm you understand, give suggestions, and then - when you point me at a file - open an interactive local-host 3D viewer I can rotate and zoom with top, front, side and underside views and a print-plate view showing orientation and size on the bed, then let me customise the model and export. Codex restates it and recommends one repo per harness; it creates a 3d-printing-harness folder (agents, config, domain rules, prompts, an app folder with a local web viewer, and a front-end design skill used for the interface). Participants built parallel versions (Rahul's skull model, Syed's dark-mode viewer). Printing: with the Mac mini wired up, he asks Codex to use the olive filament in slot 4 and to take a photo with the printer's built-in camera; Codex finds slot 4 blank in the material profile, slices an A1 job, uploads it and starts; a 25-minute print followed. Closing ideas: save nozzle travel by grouping parts closer; add an average print-time readout; print a key-puller; combine this with the anatomy skill to print mechanical parts.

The architecture he draws (red lines on the slide): the MacBook controls a Mac mini over SSH, and the Mac mini controls the 3D printer over the local network. Printer set-up: connect the Bambu app to Wi-Fi, then on the printer's small screen turn on LAN-only mode and developer mode; after that Bambu cloud no longer sees it (the account shows it as disabled), and you ask Codex (or Hermes) to scan the Wi-Fi for connected devices and connect to the printer. He introduced the Mac mini because the harness only worked while the MacBook was on the same Wi-Fi - at a cafe it stopped. The Mac mini is always on the home network and acts as a server; a Raspberry Pi would do the same. In the Codex app, Settings, Connections lets you add SSH hosts (a virtual machine, the mini); the same SSH route reaches any server. Security: use Tailscale on all your devices so only your account's machines can reach each other. A participant (Shaquille) argues Tailscale only covers devices that run it, so the printer itself is not protected; he decides to add a firewall as well because his Hermes has access to all physical devices and a stolen Tailscale account would open everything. Hermes Q&A: a Hermes on a cloud server cannot see your home Wi-Fi - that is why the Mac mini exists - though Tailscale could bridge it, and the same device could be driven by Hermes on Hostinger or by Codex directly if the computer is already on the LAN. He plans to move to an always-on local DGX Spark-class box (about 7,000 USD now, said to have doubled) rather than depend on Azure.

Inspired by a tweet from Gathin and the GitHub repo tv-vibehack (credit to the author, Gathin23), he swapped his TCL Android TV's ad-filled launcher for a minimal one with only the apps he uses (YouTube, Netflix, Hotstar, Prime) and a button that opens the Jarvis view; he asked for a liquid-glass look so it resembles Apple TV. The Jarvis view shows live Codex sessions running on his MacBook and some emails, because the harness and his Hermes agent are connected to the same CLI and mini. To make it teachable: new chat in the Desktop vertical-harness folder, paste the repo link and prompt: integrate this code base into a vertical harness connectable to my Hermes agent, ignore Hermes configuration for now, call it Android TV harness; also 'do not change the configuration of my current Android TV'. Codex built the folder with evals, domain and artifacts, hit launcher compatibility issues (a missing Android TV launch entry), tested on an emulator (APK installed on Android TV 14; home-selection quirk), and fetched the TV's serial number. Published as one repo for learners that contains the original launcher source with their changes, the Jarvis button, executable harness and device tools. Q&A: Roku TVs work, Samsung (Tizen) needs a different implementation and developer mode (tap the build number seven times; files may need a USB stick); the same approach could add tasks from the TV but he had not configured it, and he has not worked on its security. Chat idea: harnesses as paid products.

During the TV build the room raises security repeatedly: is Wi-Fi shared with neighbours a risk, can anyone on the network drive the printer, and what stops a bad actor. His position: anyone on the network can see devices but only his Tailscale-connected Hermes can command them because the printer is on LAN mode and the commands arrive through the mini; he concedes a stolen Tailscale account would give full access, so a firewall should be added and the router's default password changed. He also recalls an Anthropic research piece on AI models that may replicate themselves across smart devices (smart fridge, air fryer, Android TV boxes) on one Wi-Fi network, and shares the article link (as he describes it - the claims are unverified here); his takeaway is that firewalls and device isolation become important once harnesses control physical devices, and that models may not need big GPUs if they can spread over many small ones. He says he had not focused on security for the TV harness and will publish guidance with the repo.

Harness 3 starts from the 'anatomy' skill (a public repo) that draws interactive exploded views - a mechanical watch whose movement can be wound, a sorting desk, a Macintosh, merge sort, a token bucket, easing curves, a public key, the CSS box model, even a Starship. He says his own harness here is not special: the skill with his presentation flow. To lift it, he pastes the repo link into Codex with his Desktop vertical-harness template and asks for a presentation harness for technical decks and website design; Codex asks whether he wants a runnable HyperFrames slideshow with navigation and presenter notes, and he agrees - HyperFrames (by Adrian; agent-friendly video and slides written in HTML, a Remotion substitute). Ideas: connect the anatomy skill to the printer harness to print real mechanical parts. Harness 4 was the class's pick, financial modelling: he searches skills, finds a startup financial-modelling skill (3-5 year projections with revenue assumptions) and a Claude office-style skill, pastes both links with the template and asks for a harness connectable to Hermes, pushed as a standalone repository linked to the template; he admits he is not yet clear how to shape it and leaves it running. Wrap ideas: a harness that drafts the LinkedIn post and blog after every repo or session (build in public), asking Hermes to automate it, and a 'bring your own 3D printer' extension; he will share all repos, the Drive images (converted from HEIC) and the notes.