Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claudia – Desktop companion for Claude code

claudiacode.com

Post reply on HN
Print view View original

161–170 of 245 posts

Re: Claudia – Desktop companion for Claude code

#161

Post by dgunay »

resonious wrote: post #130
alphazard wrote: post #11

Does this sandbox the agents? All I want is a way to keep the agents from writing to and reading from arbitrary places on the filesystem. I want that enforced using operating system primitives rather than a pinky promise with an LLM. It already worries me that the Cursor agents occasionally try to perform operations with full absolute paths, which they wouldn't be able to know if they were properly sandboxed to the c…

I think OpenAI's Codex does this. Not sure to what degree, but sandboxing seems to be a priority for that project. Possibly to their detriment since last time I tried it it was not nearly as good as Claude Code.

Codex-cli does use MacOS sandboxing by default. It does unfortunately cause issues for my workflow because the agent is very restricted in what it is allowed to do (like, read/write the Go build cache) and its command whitelisting configurability is currently nonexistent. I'm looking into using containers to allow the agent more autonomy within its environment.

Re: Claudia – Desktop companion for Claude code

#162

Post by dgunay »

Here's my personal workflow. I've built a relatively small (When I want to start an agent, I run a small command that takes in a prompt (and some optional flags but mostly the defaults are what I want). It does this: 1. Check out a worktree from a repo (defaults to my bread and butter repo with completions for the most active ~5 repos in my org) 2. Craft a command to launch an agent (supports codex, opencode, and gemini-cli because my company only gives us OpenAI keys). 3. Launch the command in a tmux session. 4. Exit 0.

There are some light integrations with Jira, GitHub, etc but they're accomplished by shelling out to other tools.

If I want to manage sessions, I've got tmux + fzf + other unixy tools old & new to manage them.

If I want to manage sessions remotely, there is vibetunnel. It would be cool to have a slicker AFK experience, but it works.

My silly little piece of vibe coded slop and duct tape, for my use case, is largely competitive with most of the offerings on the market, outside of the ones that do cloud-based environments. Some of these projects are VC funded teams of people working full time, I'm assuming. What a time to be alive.

I'm also amazed at how readily projects like this just embrace Claude Code lock-in. Is there really anything specific about it that other agent harnesses don't support? I haven't used it yet, but so far it just seems like it benefits in mindshare alone from being the default/first mover, not because it supports any particular feature the others do not. TBF I do hear that it is quite good.

Quality & polish is a compelling reason to _use_ something, but it's not a compelling reason to build walls IMO, especially in a space like this where context engineering techniques, prompts, etc are in no way secret sauce and can be readily copied.

Re: Claudia – Desktop companion for Claude code

#163

Post by omneity »

mikestaas wrote: post #123
unethical_ban wrote: post #118

Earlier quoted context omitted.

I still can't figure out how to set up a completely free, completely private/no-accounts method of connecting an IDE to LM Studio. I thought it would be "Continue" extension for VS Code, but even for local LM integration it insists I sign-in to their service before continuing.

Roo code in vs code, and qwen coder in lm studio is a decent local only combo.

Strongly seconding Roo Code. I am using it in VSCodium and it's the perfect partner for a fully local coding workflow (nearly 100% open-source too so no vendor is going to pry it from my hand, "ever").

Qwen Coder 30B is my main driver in this configuration and in my experience is quite capable. It runs at 80 tok/s on my M3 Max and I'm able to use it for about 30-50% of my coding tasks, the most menial ones. I am exploring ways to RL its approach to coding so it fits my style a bit more and it's a very exciting prospect whenever I manage to figure it out.

The missing link is autocomplete since Roo only solves the agent part. Continue.dev does a decent job at that but you really want to pair it with a high performance, large context model (so it fits multiple code sections + your recent changes + context about the repo and gives fast suggestions) and that doesn't seem feasible or enjoyable yet in a fully local setup.

Re: Claudia – Desktop companion for Claude code

#164

Post by dgunay »

Aeolun wrote: post #143
commandar wrote: post #29

On the one hand, it's good that we're seeing a lot of exploration in this space. On the other, the trend seems to be everyone developing a million disparate tools that largely replicate the same functionality with the primary variation being greater-or-lesser lock-in to a particular set of services. This is about the third tool this week I've taken a quick look at and thought "I don't see what this offers me that I d…

I think the thing is that most of the people implementing stuff for Claude have already realized it’s just the best option available for… basically everything. I’ve switched to different models before, but I always come back to Sonnet or Opus for doing anything sensible.

Claude may be arguably the best model, but why decide unilaterally for your users that they _have_ to use it?

If there's no particular feature that only Claude offers, this is just needless vendor lock-in. And what happens if another lab releases a model that suddenly trounces Claude at coding? Your users will leave for an app that supports the new hotness, and you won't be able to keep them because of a short-sighted architecture that cannot swap model providers.

Re: Claudia – Desktop companion for Claude code

#167

Post by kristo »

Aeolun wrote: post #143
commandar wrote: post #29

On the one hand, it's good that we're seeing a lot of exploration in this space. On the other, the trend seems to be everyone developing a million disparate tools that largely replicate the same functionality with the primary variation being greater-or-lesser lock-in to a particular set of services. This is about the third tool this week I've taken a quick look at and thought "I don't see what this offers me that I d…

I think the thing is that most of the people implementing stuff for Claude have already realized it’s just the best option available for… basically everything. I’ve switched to different models before, but I always come back to Sonnet or Opus for doing anything sensible.

This is true for now.

I built some workflows using Claude’s API and now wish I had used a wrapper so I could easily switch to try gpt-5 for the cost savings.

Re: Claudia – Desktop companion for Claude code

#168

Post by [deleted] »

robwwilliams wrote: post #155
bigyabai wrote: post #101

Earlier quoted context omitted.

> a fixed subscription and we will no longer know the tokenomics because the provider will have greatly abstracted This is definitely not how most compute-constrained cloud services end up looking. Your cloud storage provider doesn't charge you a flat rate for 5tb/month of storage, and no amount of financier economics can get Claude there either.

Wait, aren’t you describing Dropbox?

[deleted]

Re: Claudia – Desktop companion for Claude code

#169

Post by threecheese »

dgunay wrote: post #164
Aeolun wrote: post #143

Earlier quoted context omitted.

I think the thing is that most of the people implementing stuff for Claude have already realized it’s just the best option available for… basically everything. I’ve switched to different models before, but I always come back to Sonnet or Opus for doing anything sensible.

Claude may be arguably the best model, but why decide unilaterally for your users that they _have_ to use it? If there's no particular feature that only Claude offers, this is just needless vendor lock-in. And what happens if another lab releases a model that suddenly trounces Claude at coding? Your users will leave for an app that supports the new hotness, and you won't be able to keep them because of a short-sighte…

There’s value in Anthropic being able to optimize their model’s front end to fulfill whatever features they plan for CC - like tool calling. You point out a valid risk of lock-in, maybe this signals they are committed to being at the forefront of coding models (part of enterprise play)?

Re: Claudia – Desktop companion for Claude code

#170

Post by dostick »

The desktop companion is not the problem that needs to be solved. It seems that every developer who successfully used CC and go on to create some tool for it is doing it for the wrong reasons or because they have to do just something.

CC development is not just development, not all types of development. it’s frontend JS based , and it’s backend development. Only those scenarios work.

Try creating native desktop or mobile app and it’s like a swamp of trial and error.

You have to learn by trial and error what documentation sets and instructions you have to provide at which moment and context and balance at with token cost.. it’s a multi dimensional problem for which there are no recipes that work.

On top of that your direct instructions to not use particular patterns or approaches gets forgotten and ignored y CC with later “you’re right, I should have…”. I am starting to think it’s not solvable by the user by providing docs, examples and instructions. That Claude must have native development baked in to the same level as they baked in the frontend and backend.

What I am getting to is - make a tool to manage those doc sets and contexts and instructions and allow to share those sets between users globally as recipes.

Post reply on HN