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

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.

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...)

And the reason is not technical. Technically, it is a great language.

Legally, it feels risky to most.

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.

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/

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?

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

Imagine if the CLI pulled your SSH keys or other sensitive information by mistake?

Programmers do make such mistakes all the time. I don't want to count on whether "uploading all files it can access" is intentional or a mistake.

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

Comments URL: https://news.ycombinator.com/item?id=48799732

Points: 2

# Comments: 0

This has been discussed in detail earlier - https://news.ycombinator.com/item?id=47612726

Further, on Mac OS, you can use `--mode=native` for Mac's native sandboxing (seatbelt).

> 2. Root containers run as root on the host. The "sandboxed" processes have full capabilities, as far as the kernel is concerned with them.

That's not always the case. You can run rootless containers or you can use containerization like Podman which does not run as root.

My belief is it is likely 1% or more. And likely coming in as an avalanche.

You can pass your favorite rootless Docker image using `--custom-docker-image` CLI parameter.

That's the definition of a sandbox, isn't it?

Even Python has that ability now. Also, `npm run dev` is running the script with full disk access.

Heck, Vscode/Cursor will auto-execute code if you open a project. And this has been actively used in the wild https://ashishb.net/security/contagious-interview/

So, amazing-sandbox at its core is nothing but a glorified docker command generator (in default mode).

Furthermore, you can use native sandboxing on macOS if you prefer.

If neither looks serious to you, then please educate me on a better sandboxing approach.