tterm
A terminal, a real browser, and Claude Code under one roof
154 followers
A terminal, a real browser, and Claude Code under one roof
154 followers
tterm is a macOS cockpit for working with Claude Code. Every project is a row of explorer, Claude, and file viewer. Stack as many as you're juggling. A real Chromium browser lives inside, and there's no editor on purpose: you review diffs hunk by hunk and commit. It even rebuilds itself. Ask the Claude pane for a feature and the running app hot-reloads with it. No account, no telemetry. Free for hobbyists, on Apple silicon.
Free
Launch Team
Render: Get up to $100K in startup creditsCloud infrastructure for founders who want to move fast and NOT break things
Promoted
That breakdown is exactly what I wanted — copy-once into tterm's own profile with a Keychain consent prompt is the clean answer. The part I'd still gate is the agent driving authenticated sessions: treating page text as untrusted data protects the model's reasoning, but a prompt-injected page could still steer it to navigate and submit somewhere I'm already logged in. Even before a full origin allowlist, would a read-only mode on authenticated origins (view but not click/submit) be feasible as a stopgap?
the self-rebuilding part is the thing I'd want to stress test before trusting it daily. if you ask the Claude pane for a feature and the hot-reload lands on something broken, does the app roll back to the last working build automatically, or are you stuck debugging your own cockpit while it's down? that failure mode seems like the actual risk of a tool that rewrites itself while you're using it.
@omri_ben_shoham1 in my experience, I haven't had any issues that I haven't been able to resolve with a subsequent prompt. the base version does not have checkpointing, but I will be sure to add that - thanks for pointing out!
No account and no telemetry is the right call, but the embedded Chromium carrying my Chrome bookmarks and cookies is the part I would want scoped before running this daily. Does the browser pane read my live Chrome profile directory, or a copy made at first launch? And since the Claude pane sits in the same app, can the agent drive that browser against sessions I am already authenticated into, or is agent-initiated navigation confined to a separate profile or an origin allowlist?
@hi_i_am_mimo tterm reads copies of Chrome's Bookmarks, History, and Cookies files from disk once, decrypts cookies with Chrome's own Safe Storage key from the macOS Keychain (which fires a visible one-time consent prompt), and writes everything only into tterm's own browser profile under ~/Library/Application Support/tterm. Chrome's profile directory is never written and never watched :)
Secondly, yes, the claude pane in the base version can drive the embedded browser, including pages you're signed into. Admittedly, this is still something I'm working on making better. It only runs when you explicitly send it a message, and everything it reads from pages is treated as untrusted data in its instructions. There's no origin allowlist or separate agent profile yet. That's a fair ask and I'd like to add it.
Thanks for the great questions!
The diff-by-hunk flow is genuinely clever, I'd love a small "drafted explanation" panel where I can leave notes for my future self before committing. Some commits have weird "why I did this" context that gets lost once the message is final, and writing it inline in the commit box always feels rushed. A scratchpad that auto-attaches to the commit hash would fit right in with the project-row layout you already have.
@nazkudak Love this, and this is something you can totally bake into your iteration of tterm! My fav part of all the suggestions i'm getting is that every single person can just bake in their suggestions into their tterm. Regardless, will add this to my list to add to the base version!
The bundled Chromium carrying your Chrome cookies is the detail I keep circling. I run agents against logged-in Chromium too, and each one gets its own throwaway profile on purpose: if the Claude pane can drive a browser already logged into your email or GitHub, a wrong click there executes as you, against your real accounts. That is a much bigger blast radius than a bad hot-reload. Is the in-app browser sharing your everyday Chrome session, or is it a separate profile the agent is scoped to?
@dipankar_sarkar They are on a separate profile, however, working with the user's real accounts is optional (and in my case, intentional). I have tterm do a bunch of real work which requires me to be signed in. Unfortunately that comes with the caveat of the larger blast radius :(
Appreciate you owning the tradeoff so plainly, most people would hand-wave it. Since you're clearly keeping the signed-in mode (I would too, that's where the useful work is), the thing that softened it for us was splitting read from write: the agent browses freely, but anything that changes state, a push, a delete, a purchase, waits on a one-tap confirm. Keeps most of the flow autonomous while the irreversible part stays yours. Would that fit tterm's diff-review philosophy, given you already gate commits hunk by hunk?
@dipankar_sarkar definitely would, human in the loop is much needed. Claude will often (but not always) end tasks prematurely in order to hand off the sensitive task to the user (don't ask me how I know this ;)).
Ha, I've seen that exact behavior, the model bailing right before the irreversible step and going 'you take it from here.' It's a nice instinct but I wouldn't build a guarantee on it, since the same model that stops 90% of the time will confidently push the button the other 10. What worked for us was moving the decision out of the model entirely: the confirm gate fires on the action type, any write, delete, or spend, so it's the same whether Claude flagged it or not. Then the model bailing early is a bonus, not the safety net.
@dipankar_sarkar Wouldn’t bringing a human into the loop based solely on the action type create a lot of false positives (or if your confirm gate has a lightweight model, token spend)? I’d worry that it makes the system too dependent on the user and less agentic. I may be missing some nuance though.