Write screenshots where the CLI was told to (#119) - #286
Merged
Conversation
vibium screenshot reduced -o to its basename and joined it with the screenshot dir, so every path the user typed was discarded: -o /tmp/x.png landed in ~/Pictures/Vibium/x.png. The daemon is a separate long-lived process, so it cannot resolve a relative path against the user's shell. The CLI now resolves -o itself and sends an absolute path; the daemon writes an absolute path as given and creates any missing parent directories. A bare filename still goes to the screenshot dir, which keeps the MCP default (~/Pictures/Vibium) intact. That default exists because an agent has no working directory the user can see; a developer typing into a terminal does, so the CLI now writes there. Adds docs/how-to-guides/screenshots.md.
This was referenced Aug 3, 2026
hugs
added a commit
that referenced
this pull request
Aug 4, 2026
vibium pdf -o and vibium record stop -o hand the path to the daemon, whose working directory is not the caller's, so a relative path landed wherever the daemon happened to be started while the command reported success. #286 fixed this for screenshot and stopped there. These are the same bug in the two sibling commands. storage -o was already fine: it writes the file client-side. pdf also now creates missing parent directories, which screenshot and record already did.
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.
vibium screenshotreduced-oto its basename and joined it with the screenshot dir, so any path you typed was discarded:Why it could not just be fixed in the daemon
The daemon is a separate long-lived process started from some other directory, so it cannot resolve a relative path against the user's shell. The CLI resolves
-oitself and sends an absolute path; the daemon writes an absolute path as given and creates missing parent directories. Same patternstorage restorealready uses.The default changed too, on purpose
vibium screenshotwith no-onow writes./screenshot.pnginstead of~/Pictures/Vibium/screenshot.png.The old default predates the CLI. It was designed for MCP, where the caller has no working directory the user can see, so a fixed findable location is the only sensible answer. A developer typing into a terminal does have one, and expects it to be used.
MCP behavior is unchanged. A bare filename still lands in the screenshot dir, and MCP only ever sends bare filenames, so
~/Pictures/Vibiumremains the agent default and--screenshot-dirstill works.Verified
New regression test in
tests/cli/navigation.test.jsfails against the pre-fix binary and passes after. Fullmake testpasses.Docs
docs/how-to-guides/screenshots.md(new) covers CLI paths, capture options, and the MCP default.docs/tutorials/getting-started-mcp.mdnow says why the MCP default differs from the CLI.Supersedes #119, which reported this and fixed the daemon half.