You would have had to run `jj edit` in order for this to happen, so I think it's a stretch to say you didn't ask for the edit?
This is the main difference though: in git files can be `staged`, `unstaged` or `committed`, so at any one time there are 3 entire snapshots of the repo "active".
In `jj` there is only one kind of snapshot (a change) and only one is "active" (the current working directory). When you make changes to the working directory you are modifying that "change".
As others have mentioned, the equivalent to `git checkout` would be `jj new`, which ensures a new empty change exists above the one you are checking out, so that any changes you make go into that new change rather than affecting the existing one.
Using `jj edit` will edit a commit you specify, and `jj new` will make a new empty commit after the one you specify. These work exactly the same whether you specify a commit by branch or by the hash. I'd argue that you're getting exactly what you ask for with these commands, and by comparison, what "checkout" is asking for is much less obvious (and depends on context). We've just internalized the bad behavior of git for so long that it's become normalized.
But even then, the agent can still exfiltrate anything from the sandbox, using curl. Sandboxing is not enough when you deal with agents that can run arbitrary commands.
If you're worried about a hostile agent, then indeed sandboxing is not enough. In the worst case, an actively malicious agent could even try to escape the sandbox with whatever limited subset of commands it's given.
If you're worried about prompt injection, then restricting access to unfiltered content is enough. That would definitely involve not processing third-party input and removing internet search tools, but the restriction probably doesn't have to be mechanically complete if the agent has also been instructed to use local resources only. Even package installation (uv, npm, etc) would be fine up to the existing risk of supply-chain attacks.
If you're worried about stochastic incompetence (e.g. the agent nukes the production database to fix a misspelled table name), then a sandbox to limit the 'blast radius' of any damage is plenty.
That argument seems to assume a security model where the default prior is « no hostile agent ». But that’s the problem, any agent can be made hostile with a successful prompt injection attack. Basically, assuming there’s no hostile agent is the same as assuming there’s no attacker. I think we can agree a security model that assumes no attacker is insufficient.
Code is not the only thing the agent could exfiltrate, what about API keys for instance? I agree sandboxing for security in depth is good, but it’s not sufficient and can lull you into a false sense of security.
This is what emulators and separate accounts are for. Ideally you can use an emulator and never let the container know about an API key. At worst you can use a dedicated account/key for dev that is isolated from your prod account.
VM + dedicated key with quotas should get you 95% there if you want to experiment around. Waiting is also an option, so much of the workflow changes with months passing so you’re not missing much.
That depends on how you configure or implement your sandbox. If you let it have internet access as part of the sandbox, then yes, but that is your own choice.
Internet access is required to install third party packages, so given the choice almost no one would disable it for a coding agent sandbox.
In practice, it seems to me that the sandbox is only good enough to limit file system access to a certain project, everything else (code or secret exfiltration, installing vulnerable packages, adding prompt injection attacks for others to run) is game if you’re in YOLO mode like pi here.
A tale as old as time: hubris. A successful system is destined to either stop growing or morph into a monstrosity by taking on too many responsibilities. It's hard to know when to stop.
React lost me when it stopped being a rendering library and became a "runtime" instead. What do you know, when a runtime starts collapsing rendering, data fetching, caching, authorization boundaries, server and client into a single abstraction, the blast radius of any mistake becomes enormous.
Alas, that’s a common misconception! You’re confusing properties with attributes. Attributes are set through HTML and are stringly typed, but litjs properties can be any js value.
For instance, I have a project with a small web component that displays data from a duckdb wasm connection. The connection object is passed as a property and it works flawlessly.
If you’re using it with something like React, passing attributes is easy, but setting properties is much harder, requiring using the escape hatches—I believe you’ll need useRef and useEffect, and a bit of care because it’s frightfully easy to do the wrong thing.
> Server Side Rendering: props passed to a custom element will render as attributes if their type is a primitive value like string, number, or the value is true. Props with non-primitive types like object, symbol, function, or value false will be omitted.
> Client Side Rendering: props that match a property on the Custom Element instance will be assigned as properties, otherwise they will be assigned as attributes.
> As of v19, React now uses a runtime heuristic to determine if it should pass data to Custom Elements as either properties or attributes. If a property is already defined on the element instance, it will use properties, otherwise it will fallback to attributes.
All up it sounds fragile, and I’m not fond of how JSX syntax makes properties look like attribute, and I hate the way you lose the sometimes-crucial distinction of whether something is a property or an attribute (<input value> is the most obvious example of this), but I guess it’ll be fine in practice. I’m a little curious how they handle some of the event stuff, since React’s synthetic event system is such a legacy mess. And I never did like the way several popular libraries/frameworks (definitely not just React) special-case /^on.*/ attributes, so stupid how you now can’t safely use an attribute or property named “once”, “one” or “online”, all of which would be the most sensible name in certain situations.
I'm all for building more housing, as long as it comes with the necessary infrastructure - schools, roads, parking, public transportation, etc. Where I live, developers seem to get government approval to build in locations where they can rake in a lot of money at high prices without having to worry about such things.
(In fact, my local government is actually closing roads near new housing because "f#ck cars" is apparently a hip idea these days.)
There’s a puzzling contradiction between your claim that developers are the problem, on one hand, and then your own anecdote on the other, not to mention the article that very convincingly debunks the idea that housing shortage is the fault of developers. I must be missing something, because frankly this isn’t making any sense.
I'm not saying that developers are the cause of the housing shortage.
I'm saying that developers are eager to build housing and sometimes are able to cut corners via undue influence over public officials. That leads to more housing (good), but it also erodes the quality of life for residents (bad).
Indeed, that is the only alternative and the favoured option for those trying to make it safe for their kids to bike to school. Though I prefer mules myself.
Have you tried getting back into cardio with a softer method like biking? Maybe that combined with some strength exercices could toughen up your body enough that you can start running again! Anyway, best wishes.
reply