docs(sandbox): correct two false mechanisms in the cursor comment - #854
Open
orveth wants to merge 1 commit into
Open
docs(sandbox): correct two false mechanisms in the cursor comment#854orveth wants to merge 1 commit into
orveth wants to merge 1 commit into
Conversation
The install-script paragraph explained itself with a user that does not exist. It said /root/.local is unreadable by "the `agent` user this image runs as"; there is no `agent` user, the image creates none, and it sets no USER at all — so a bare `docker run` is root. The decision to take the tarball is unchanged and the real mechanism is worse. Jobs arrive as a host uid through `docker run --user`, which this file already documents 100 lines below. So a /root/.local install is readable by a bare `docker run` and unreadable by every real job: it passes exactly the test someone would think to run, and fails only when a buyer's sats are on it. `cursor-agent` is also not the program. It is 1,074 B of bash that execs the package's own bundled node (dist-package/node, ~129 MB), so this image's /usr/local/bin/node does not run cursor. That strengthens the reason for digesting the tarball — the digest has to cover the interpreter, not just the .js beside it — and it moves the open gVisor question onto a different binary, alongside the `cursorsandbox` and `crepectl` helpers the package ships. Comment-only, and proven rather than asserted: strip every comment and blank line from this file at main and at this head and the two are byte-identical. Zero instruction lines differ. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two statements in the sandbox Dockerfile's cursor comment were false. Both are the kind that end a reader's search, because each explains a real decision with a mechanism that does not exist.
The install-script paragraph named a user that does not exist
It said the script's
/root/.localinstall "theagentuser this image runs as cannot read". There is noagentuser./etc/passwdin the built image has one non-system entry,node:x:1000:1000, and the image sets noUSERat all — so a baredocker runis root.The decision to take the tarball instead of the script is still right, and the real mechanism is worse than the one written down. Jobs arrive as a host uid through
docker run --user, which the same file already documents 100 lines further down. So an install under/root/.localis readable by a baredocker runand unreadable by every real job. It would pass exactly the test someone would think to run, and fail only when a buyer's sats are on it.cursor-agentis not the programThe comment described a "4 KB launcher script, not the bundled Node application it execs". Measured: the launcher is 1,074 B of bash, and it execs the package's own bundled node —
dist-package/node, ~129 MB. This image's/usr/local/bin/nodedoes not run cursor.That matters beyond the byte count. The reason for digesting the tarball rather than the launcher is stronger than stated: the digest has to cover the interpreter too, not just the
.jsbeside it. And it moves the open gVisor question onto a different binary. "Node is the best-exercised workload on runsc" is a claim about the image's node, which is not the one that has to survive. The package also shipscursorsandboxandcrepectl— the class of helper that reaches for namespace syscalls runsc may not implement.This cannot change the image
Comment-only, and proven rather than asserted: strip every comment and blank line from this file at
mainand at this head, and the two are byte-identical. Zero instruction lines differ. The--versiongate, the digests, the arch mapping and the layout check are all untouched.Sequencing
Nothing here gates rc3. It is a correction to what the file tells the next reader, not to what it does.
🤖 Generated with Claude Code