ashishb

It is good but you still don't want long running background tasks.

When you run a linter, for example, then it should stop executing cider once it stops. And not be able to spawn long-running background tasks for infiltration.

Don't mount all your code every time.

E.g. when working on a frontend only project, you don't need to mount the backend directory and vice-versa. This limits the attack radius.

Dedicated user account does not work as eventually all your code and data will move under that.

I run it in an ephemeral container sandbox (https://github.com/ashishb/amazing-sandbox) which has access to the current working directory and it drastically limits the attack radius.

The extensions does not need full access to the laptop.

When you are invited to someone's living room, you don't get to access their bedroom.

The idea that Claude should have full data access to the home directory is wrong. And as an industry leader, Claude has set a bad precedence.

Exactly, that's what I do, I even up end up writing my own for this purpose - https://github.com/ashishb/amazing-sandbox

Yeah, dev containers indeed has better integrations.

It is fairly useless if you want to run a random tool like a linter on a random file(s)

For expensive toddler food, they use blackberry and other fruits (with fiber removed), so, the sugar ratio to fiber ratio is high.

And they can simultaneously claim no sugar added

https://ashishb.net/parenting/misleading-food/

I believe the goal, in such cases, is not to save money but rather make the food more addictive for the child.

> Granting terminal full disk access grants arbitrary scripts full disk access.

Indeed, I run all dev tools including coding agents inside sandbox now

https://github.com/ashishb/amazing-sandbox

React native is broadly an inferior option.

LLMs made it way worse https://ashishb.net/tech/react-native/

Try https://github.com/ashishb/amazing-sandbox

You give implicit access to current directory and can mount as many custom volume mounts as you would like. And it is FOSS.

I wrote this for myself and have been using it regularly.

It is FOSS

https://github.com/ashishb/amazing-sandbox

The archaic model where every tool gets full access to your home directory was never designed for the scenario where a single npm install will install and execute 100s of packages written by various authors.

One should sandbox all npm command executions.

This is true for all CLI tools on Mac and Linux (and other operating systems from that era).

Historically, everything you ran was trustworthy.

Android and iOS were invented in an era that does not allow this because the risks became evident by then.

> The repo you’re working on, sure. But all files?

Yes, any tool, including any coding agent, has access to all files $USER has access to.

Sandbox it explicitly to give access to only the current directory - https://github.com/ashishb/amazing-sandbox

> That every other vowel letter also can is English's low level of phoneticism

The level of phoneticism between English language and its latin script is not evenly spread.

For example, the letter "c" might mean /s/ or /k/ sound. However, the letter "k" almost certainly means /k/ sound.

In some ways, the schwa sound in English the worst as there is no symbol which is committed even partially towards it.

> it is Rāma, and 'a' represents the schwa.

Sure, but if my name is Rāma, I have to choose either "Ram" or "Rama" or "Raama" for my passport name. Or legal name in most places, non-alphabetic symbols do not work with all modern systems.

> Many other languages using the Latin script (German, Italian, Finnish) don't have this problem, what you see is what get.

English imports spellings from other cultures and adds its own layer of pronunciations. Other languages probably don't do it as often.

> It's Ram, not Rama, it's yog, not yoga'... And they have no idea what schwa deletion is.

It is neither.

The fundamental issue is that there is no way to represent the schwa sound in English[1]. All of a,e,i,o,u have been used to communicate the schwa (or schwa-like) sound in English.

  - The `a` in about
  - The `e` in taken
  - The `i` in cousin
  - The `o` in button
  - The `u` in upon

1 - https://ashishb.net/linguistics/schwa/

Many of my friends are surprised that I purchase mp3s and store them in Google Drive instead of listening on Spotify or YouTube.

Heck, I even wrote a player for this [1] The problem is that licensed media like this are always going to become inaccessible over decades.

It happened with Apple[2] and Microsoft (PlaysForSure[3]) as well.

1 - https://musicsync.ashishb.net/ 2 - https://www.nytimes.com/wirecutter/blog/you-dont-own-your-di... 2 - https://www.cnet.com/culture/playsforsure-officially-dead/

> Are you actually claiming English isn't a mother tongue to anyone?

I gave a specific example where neither the coffee wholesaler nor the buyer probably operates day to day in English. But they would still use English for the official agreement.

That does not take away from other benefits of English like being spoken by millions as a primary language and probably billions as a second language

> Sanskrit was widely spoken and understood just like Latin or Avestan, in its heyday. Otherwise it wouldn’t be part of the liturgical traditions of Buddhism, Jainism and Nastika traditions.

I think, and it is just my speculation, that for most of Indian History, Sanskrit was the link language.

Just like "Latin" in the USA and Europe of the early 17th and 18th centuries, when all academic instructions were carried out in Latin!

So, nobody used Sanskrit as the primary language, but everyone could or knew someone who could convert Sanskrit to the local dialect.

It is almost like how Chinese and Colombian traders might sign a contract for coffee purchase in English. Neither might use English in most of their daily operations.

> What about Prakrit and Punjabi?

There is no official "Prakrit", by definition of the term itself. "Prakrit" just means "natural" and the way I understand it, was the term for all colloquial dialects/languages across India.

"Sanskrit", on the other hand, meant "cultured" and its grammar, at least for the last 2500 years, is strictly defined by Panini (https://en.wikipedia.org/wiki/A%E1%B9%A3%E1%B9%AD%C4%81dhy%C...)

Fun fact: the famous "Sentosa" island in Singapore is a spelling variation of the same word.

I think most organizations don't want to increase their Java usage.

And the reason is not technical. Technically, it is a great language. Legally, it feels risky to most.

That's why I intentionally restrict these AI agents to exactly one directory ($CWD)

https://github.com/ashishb/amazing-sandbox

Languages do matter.

And I think the only sensible backend languages when starting a new for-profit project is Python, Go, and Rust for 99% use-cases.

In other cases, third-party packages, tooling, integrations, and telemetry starts to suffer.

> Because I'm confident nothing will happen if it does

Well, best of luck.

1. Amazon has shipped backdoored packages - https://aws.amazon.com/security/security-bulletins/AWS-2025-... 2. Scanners like Trivy have been compromised - https://socket.dev/blog/trivy-under-attack-again-github-acti... 3. Redhat is shipping backdoored FOSS packages - https://access.redhat.com/security/vulnerabilities/RHSB-2026... 4. Even fake and malicious ESLint packages have been published - https://gbhackers.com/eslint-package-attack/

> But in this particular case isn't the problem that it's sending everything in the sandbox?

If a CLI is touching certain files, they are likely to be leaked one way or the other.

Why not reduce the attack surface?

When does someone visit your house? Do they get unfettered access to your bedroom & safe as well?

And I run most of them inside sandbox now.

Why would you let a markdown linter access your ssh keys?