[Bug]: [blender] render execute never invokes Blender but exits 0

Author: Surya-koushikCreated Aug 25, 2026Updated Aug 25, 2026

Affected Software/Harness

blender (cli-anything-blender)

Version / Commit

cli-anything-blender 1.0.0 (via cli-hub info blender), cli-anything-hub 0.4.1

Operating System

Windows

Python Version

3.13.13

Steps to Reproduce

Blender 5.2 is installed and resolvable on PATH-equivalent lookup on this machine (confirmed present at its default Program Files install location before testing) — this is not a missing-binary condition.

cli-anything-blender scene new -o scene.blend-cli.json
cli-anything-blender --project scene.blend-cli.json object add cube
cli-anything-blender --project scene.blend-cli.json render execute ./out.png
echo Exit code: %ERRORLEVEL%
dir
tasklist | findstr /I blender

Expected Behavior

Either Blender actually renders out.png (the CLI should invoke the blender --background --python <script> command it prints), or, if it intentionally only stages a script without running it, the command should say so unambiguously and/or exit non-zero — not print a line that reads as an execution report while doing nothing.

Actual Behavior

The command prints output that reads like a completed action:

Render script generated: <path>\_render_script.py
script_path: <path>\_render_script.py
output_path: <path>\out.png
engine: CYCLES
resolution: 1920x1080
samples: 128
format: PNG
animation: False
command: blender --background --python <path>\_render_script.py
frame: 1

Exit code is 0. _render_script.py is written to disk (confirmed non-empty, ~3.3KB). But:

  • No blender.exe process is ever spawned — checked with tasklist | findstr /I blender immediately after the command returns; blender never appears, whereas launching Blender manually with the same generated script does spawn and hold a blender.exe process for the duration of the render.
  • out.png is never created — the target directory has no such file after the command completes.

So render execute generates a render script and prints the shell command that would run it, but never actually calls subprocess.run() (or equivalent) on that command. The exit code and the "command:"/"output_path:" lines look exactly like a normal successful-render report, so a caller (human or agent) has no signal that nothing was rendered.

Separately, worth flagging as a related but distinct issue: on a non-UTF-8 console (default cp1252 on an English-locale Windows terminal, not just the GBK case in #418), running any command in this harness that hits an internal error can itself crash with UnicodeEncodeError before the real error is shown — I only got the trace above by setting PYTHONUTF8=1 first. Without it, render execute prints only Error: 'charmap' codec can't encode characters in position 128-129: character maps to <undefined> and exits 1, which completely masks the actual "silently did nothing, exited 0" behavior above and looks like an unrelated, generic failure.

Relevant Logs / Tracebacks

With --json:

{"error": "'charmap' codec can't encode characters in position 128-129: character maps to <undefined>", "type": "UnicodeEncodeError"}

(This is the masking error seen without PYTHONUTF8=1 set; setting it surfaces the actual exit-0/no-op behavior described above.)

Additional Context

Related but distinct from #343 (closed) — that issue is about a SyntaxError inside the generated script's content when a user manually runs it with Blender. This report is about render execute itself never invoking Blender at all, regardless of the generated script's content.

Suggested fix: have render execute actually subprocess.run([...]) the command it currently only prints (surfacing Blender's own stdout/stderr and exit code to the caller), or, if that's out of scope for this release, at minimum change the exit code and wording so a non-zero exit / explicit "not executed, run this yourself" message is impossible to mistake for a completed render.