Repository navigation
v0.12.0 exits 0 and writes no output file on ubuntu-24.04 runners; v0.11.0 records the same tape #787
Description
Activity
Same symptoms when attempting to package vhs 0.12.0 for Void Linux.
I'm speculating that the issue lies somewhere in the ffmpeg invocation, but the fact that vhs seemingly doesn't check for or report any errors, or even have a verbose option to get more info from the tools it runs, doesn't help.
Here https://github.com/charmbracelet/vhs/blob/main/evaluator.go#L186 the context used for rendering (the line below) is cancelled.
One potential fix could be to use different contexts for rendering and recording.- added a commit that references this issue
on Sep 11, 2026 - added a commit that references this issue
on Sep 13, 2026 - added a commit that references this issue
on Sep 13, 2026 Same, reverted to 0.11 for now. Still LOVE the tool!
Reacted by soumalya dassame here i got the same issue but locally in my cachyos+hyprland (ml4w) setup i checked ttyd ffmpeg vhs all version all deps everything but a gif is never produced
edit: use
cd /tmp curl -fL -o vhs.tar.gz https://github.com/charmbracelet/vhs/releases/download/v0.11.0/vhs_0.11.0_Linux_x86_64.tar.gz tar -xzf vhs.tar.gz sudo install -Dm755 vhs_0.11.0_Linux_x86_64/vhs /usr/local/bin/vhs vhs --versionand the gif also rendered for my case too using 0.11.0
Reacted by soumalya dasReacted by soumalya dasSame failure on macOS, and both open fixes work there.
Environment: macOS 26.6.2 arm64, vhs 0.12.0 (Homebrew bottle), Chrome 153.0.8010.36, ffmpeg 9.0.1, ttyd 1.7.7, Go 1.27.1.
Results with a six-line tape:
Build Exit Output Homebrew 0.12.0 0 no file #788 at 7e0c332 0 400x200 GIF, 33 frames #789 at 2f00c0e 0 400x200 GIF, 33 frames With
VHS_TEST_BROWSER=1, the new tests pass on both branches. As a control, I restoredevaluator.goandvhs.gofrom v0.12.0 on the #789 branch and reranTestRenderWritesOutput. It failed withno output written, so the test catches this bug.Before finding these PRs I patched it locally with
v.Render(context.WithoutCancel(ctx)). That also produces a file, but it ignores cancellation of the parent context during encoding. The separate recorder context in #788 and #789 avoids that.Reacted by soumalya das and la-force-tranquille- added 6 commits that reference this issue
on Sep 14, 2026 - added a commit that references this issue
on Sep 15, 2026 11 remaining items
- added a commit that references this issue
on Sep 19, 2026 - added a commit that references this issue
on Sep 19, 2026 Independent repro, macOS 26.6.2 arm64 (Homebrew vhs 0.12.0, ttyd 1.7.7, ffmpeg 9.0.1).
One extra data point not covered above: downgrading ffmpeg does NOT fix it. With
ffmpeg@7.1.5first on PATH (same tape, minimal 6-line repro:Output test.gif+ singleType+Enter+Sleep), behavior is identical —Creating test.gif...+ publish hint + exit 0 + no file anywhere on disk (searched/tmp, cwd, tape dir, and~/Library).Test matrix on this machine:
Build Result vhs 0.12.0 (bottle) exit 0, no file vhs 0.12.0 + ffmpeg@7.1.5 on PATH exit 0, no file (same) ttyd standalone healthy — serves sessions, HTTP 200, stays alive frame capture (per @gauravbluepi) n/a tested here, but recording side completes Also reproduced from a real PTY in an interactive terminal pane (not CI/sandbox), and with tapes containing real API calls — so no sandbox/PTY excuse. Matches @gtartari-eurofunk's context-cancellation diagnosis: the encode step is cancelled before it starts regardless of ffmpeg version. Confirming the fix PRs (#788/#789) are the way forward; will report back if a mainline build changes anything on this machine.
- added a commit that references this issue
on Sep 21, 2026 - added a commit that references this issue
on Sep 24, 2026 This is so crazy. Sorry for the long review. Please, cc me next time something like this comes up.
For anyone curious, this bug was caused by linting, which is why i didn't think to check.
Sorry for the inconvenience, everybody, will release now.
Reacted by soumalya das, M. Oppenheymu and Justin HonoldReacted by M. Oppenheymu, Garrit Franke, Marius Nedelcu and Justin HonoldReacted by Justin Honold- added a commit that references this issue
on Sep 24, 2026 - added 4 commits that reference this issue
on Sep 25, 2026 - added a commit that references this issue
on Sep 26, 2026 - added a commit that references this issue
on Oct 8, 2026 - added a commit that references this issue
on Oct 9, 2026
On an
ubuntu-24.04GitHub Actions runner, vhs v0.12.0 runs a tape to completion, printsCreating <file>.gif..., prints the publish hint, exits 0, and writes no file. v0.11.0 records the same tape on the same runner without complaint.The gap between the two printed lines is about 200 to 440 milliseconds, which is far too short to encode twenty seconds of terminal, so it looks like the encode never starts rather than failing.
Controlled comparison
Two runs of the same job, on the same runner image, from two commits whose only functional difference is the version passed to
charmbracelet/vhs-action@v2.1.1:The diff between the two commits is one line plus comments:
Both runs are public, so the full logs are readable.
Environment
Tape
trustdiffis a CLI on PATH; any command that prints a screen of text and ends with a line matching theWait+Screenpattern should do.Observed
Every tape step executes and every
Wait+Screenmatches, so the terminal side is working. Then:vhs docs/demo.taperun by hand in the same job exits 0. Afterwardsdocs/contains no gif, andfind / -name 'demo.gif' -type f -newermt '-5 minutes'finds nothing.Ruled out
Four things, each tested on its own before the version was suspected:
Set Columns/Set Rows. The tape originally used them, and they are new in v0.12.0, so they were the obvious suspect. Replacing them withSet Width/Set Heightchanged nothing.ubuntu-24.04image does not carry ffmpeg. Installing it changed nothing here, but see the note below.Hide/Showblock. The tape warmed a cache off camera inside one. Removing it entirely changed nothing.Possibly a separate issue
vhs does not appear to check for ffmpeg before starting, and a run without it fails in exactly the shape above: tape completes,
Creating ....gif...prints, exit 0, no file. That made this bug considerably harder to isolate, because the first thing anyone checks produces the same symptom. A startup check, or an error when the encode produces nothing, would turn both cases into something a reader can act on. Happy to open that separately if you would rather keep them apart.Thanks for vhs. The recording it produces is exactly what the project wanted.