fix(voice): remove return-in-finally to fix Python 3.14+ SyntaxWarning by liuhao1024 · Pull Request #21100 · NousResearch/hermes-agent

liuhao1024 · 2026-05-07T08:38:32Z

What does this PR do?

Removes the return statement inside the finally block of _voice_stop_and_transcribe to fix the SyntaxWarning emitted by Python 3.14+.

Root Cause

The finally block in _voice_stop_and_transcribe (cli.py) contains a return statement used to exit after 3 consecutive no-speech detections. Python 3.14+ emits SyntaxWarning: 'return' in a 'finally' block because this pattern silently suppresses any in-flight exception propagating through the finally clause.

Fix

Replace the return with a _stop_continuous flag. The flag is set when the 3-strike no-speech limit is reached, and the restart-recording guard checks the flag to skip the auto-restart. This preserves the original behavior (stop continuous mode after 3 consecutive no-speech cycles) without suppressing exceptions.

This is a rebased version of the original PR — only the return-in-finally fix is included, all unrelated changes have been removed.

Related Issue

Fixes #21088

Type of Change

🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

cli.py: Replaced return inside finally block of _voice_stop_and_transcribe with a _stop_continuous flag
cli.py: Added not _stop_continuous guard to the restart-recording condition

How to Test

Run python3 -m pytest tests/tools/test_voice_cli_integration.py -q — should pass (84 tests)
Verify no SyntaxWarning with python3 -W error::SyntaxWarning -c "import ast; ast.parse(open('cli.py').read())" — should pass with no output
Observed result: All 84 voice CLI integration tests pass; no SyntaxWarning emitted

Checklist

Code

I've read the Contributing Guide
My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
I searched for existing PRs to make sure this isn't a duplicate
My PR contains only changes related to this fix/feature (no unrelated commits)
I've run pytest tests/ -q and all tests pass
I've added tests for my changes (required for bug fixes, strongly encouraged for features)
I've tested on my platform: macOS 26.4.1

Documentation & Housekeeping

I've updated relevant documentation (README, docs/, docstrings) — or N/A
I've updated cli-config.yaml.example if I added/changed config keys — or N/A
I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
I've updated tool descriptions/schemas if I changed tool behavior — or N/A

…HOME (#35027 regression) (#38556) The stage2 hook gates the recursive chown of the build trees under $INSTALL_DIR (.venv, ui-tui, node_modules) so a HERMES_UID/PUID remap leaves them writable by the new runtime UID — needed for lazy_deps 'uv pip install' of platform extras (#15012, #21100) and the TUI esbuild rebuild into ui-tui/dist (#28851). #35027 folded that chown under the $HERMES_HOME ownership check ('stat $HERMES_HOME != hermes_uid'). But 'usermod -u <new> hermes' re-chowns the hermes home dir ($HERMES_HOME == /opt/data) to the new UID as a side effect, so after any remap that stat is already satisfied and needs_chown is false — silently skipping the build-tree chown on the common PUID/NAS path. The venv stays owned by the build-time UID (10000), so lazy installs and TUI rebuilds fail with EACCES. Probe the build trees directly instead: chown only when /opt/hermes/.venv is not already owned by the runtime hermes UID. Independent of $HERMES_HOME ownership, idempotent across restarts. Verified live: built the image, booted with HERMES_UID/HERMES_GID on a fresh named volume, confirmed .venv/ui-tui/node_modules end up owned by the remapped UID and 'uv pip install' into the venv succeeds; confirmed the recursive chown fires once and is skipped on restart.

…HOME (NousResearch#35027 regression) (NousResearch#38556) The stage2 hook gates the recursive chown of the build trees under $INSTALL_DIR (.venv, ui-tui, node_modules) so a HERMES_UID/PUID remap leaves them writable by the new runtime UID — needed for lazy_deps 'uv pip install' of platform extras (NousResearch#15012, NousResearch#21100) and the TUI esbuild rebuild into ui-tui/dist (NousResearch#28851). NousResearch#35027 folded that chown under the $HERMES_HOME ownership check ('stat $HERMES_HOME != hermes_uid'). But 'usermod -u <new> hermes' re-chowns the hermes home dir ($HERMES_HOME == /opt/data) to the new UID as a side effect, so after any remap that stat is already satisfied and needs_chown is false — silently skipping the build-tree chown on the common PUID/NAS path. The venv stays owned by the build-time UID (10000), so lazy installs and TUI rebuilds fail with EACCES. Probe the build trees directly instead: chown only when /opt/hermes/.venv is not already owned by the runtime hermes UID. Independent of $HERMES_HOME ownership, idempotent across restarts. Verified live: built the image, booted with HERMES_UID/HERMES_GID on a fresh named volume, confirmed .venv/ui-tui/node_modules end up owned by the remapped UID and 'uv pip install' into the venv succeeds; confirmed the recursive chown fires once and is skipped on restart.

The WhatsApp setup wizard (hermes_cli/main.py, setup_whatsapp) runs `npm install` in /opt/hermes/scripts/whatsapp-bridge at first use to build the Node bridge's node_modules. That dir ships owned by the build UID (10000) via `COPY --chown=hermes:hermes . .`, and stage2-hook.sh's build-tree re-chown after a HERMES_UID/PUID remap covers .venv, ui-tui, gateway and node_modules but not scripts/whatsapp-bridge, so the install fails with `EACCES: permission denied, mkdir '/opt/hermes/scripts/whatsapp-bridge/node_modules'`. Add scripts/whatsapp-bridge to the re-chown set so the wizard's npm install can create node_modules as the remapped hermes user. Same class of EACCES already fixed for .venv (NousResearch#15012, NousResearch#21100), ui-tui (NousResearch#28851) and gateway (NousResearch#27221).

…HOME (#35027 regression) (#38556) The stage2 hook gates the recursive chown of the build trees under $INSTALL_DIR (.venv, ui-tui, node_modules) so a HERMES_UID/PUID remap leaves them writable by the new runtime UID — needed for lazy_deps 'uv pip install' of platform extras (#15012, #21100) and the TUI esbuild rebuild into ui-tui/dist (#28851). #35027 folded that chown under the $HERMES_HOME ownership check ('stat $HERMES_HOME != hermes_uid'). But 'usermod -u <new> hermes' re-chowns the hermes home dir ($HERMES_HOME == /opt/data) to the new UID as a side effect, so after any remap that stat is already satisfied and needs_chown is false — silently skipping the build-tree chown on the common PUID/NAS path. The venv stays owned by the build-time UID (10000), so lazy installs and TUI rebuilds fail with EACCES. Probe the build trees directly instead: chown only when /opt/hermes/.venv is not already owned by the runtime hermes UID. Independent of $HERMES_HOME ownership, idempotent across restarts. Verified live: built the image, booted with HERMES_UID/HERMES_GID on a fresh named volume, confirmed .venv/ui-tui/node_modules end up owned by the remapped UID and 'uv pip install' into the venv succeeds; confirmed the recursive chown fires once and is skipped on restart.

…HOME (NousResearch#35027 regression) (NousResearch#38556) The stage2 hook gates the recursive chown of the build trees under $INSTALL_DIR (.venv, ui-tui, node_modules) so a HERMES_UID/PUID remap leaves them writable by the new runtime UID — needed for lazy_deps 'uv pip install' of platform extras (NousResearch#15012, NousResearch#21100) and the TUI esbuild rebuild into ui-tui/dist (NousResearch#28851). NousResearch#35027 folded that chown under the $HERMES_HOME ownership check ('stat $HERMES_HOME != hermes_uid'). But 'usermod -u <new> hermes' re-chowns the hermes home dir ($HERMES_HOME == /opt/data) to the new UID as a side effect, so after any remap that stat is already satisfied and needs_chown is false — silently skipping the build-tree chown on the common PUID/NAS path. The venv stays owned by the build-time UID (10000), so lazy installs and TUI rebuilds fail with EACCES. Probe the build trees directly instead: chown only when /opt/hermes/.venv is not already owned by the runtime hermes UID. Independent of $HERMES_HOME ownership, idempotent across restarts. Verified live: built the image, booted with HERMES_UID/HERMES_GID on a fresh named volume, confirmed .venv/ui-tui/node_modules end up owned by the remapped UID and 'uv pip install' into the venv succeeds; confirmed the recursive chown fires once and is skipped on restart.

teknium1

Thanks for identifying the Python 3.14 warning. The voice premise is still present on current main: cli.py:11305-11328 has a return inside _voice_stop_and_transcribe's finally block, so the focused control-flow fix is worth salvaging.

Problems

tools/file_tools.py:922 makes mutually exclusive replace-mode and patch-mode arguments all JSON-schema-required. Current main deliberately keeps only mode required and documents per-mode requirements (tools/file_tools.py:2051-2093; 3adcc6441916c40f0c5135e65194ff9642c99f29).
tests/tools/test_voice_cli_integration.py:1332 does not stop at a sibling class method, so its line scanner is not reliably scoped to _voice_stop_and_transcribe.
The WhatsApp timeout change has already landed (1a4e8f70415e073db257c4a31908c21e9921dd5b) and now lives in plugins/platforms/whatsapp/adapter.py:545.

Suggested changes

Salvage only the voice hunk and replace the source scanner with an AST-scoped assertion plus a three-silent-captures behavior test.

Automated hermes-sweeper review.

teknium1 · 2026-07-12T23:48:24Z

        },
-        "required": ["mode"]
+        "required": ["mode", "path", "old_string", "new_string", "patch"]


mode selects mutually exclusive payloads, so requiring both all replace fields and patch makes valid calls schema-invalid. Keep required as ["mode"] and retain description-level per-mode requirements, as current main does in tools/file_tools.py:2051-2093.

teknium1 · 2026-07-12T23:48:24Z

+                if not stripped or stripped.startswith("#"):
+                    continue
+                # Detect method end (next def/class at same or lower indent)
+                if (stripped.startswith("def ") or stripped.startswith("class ")) and not line.startswith("    "):


This does not stop at the next HermesCLI method because sibling methods start with four spaces. Use ast to locate _voice_stop_and_transcribe and inspect only its Try.finalbody nodes.

Replace the return statement inside the finally block of _voice_stop_and_transcribe with a _stop_continuous flag. Python 3.14+ emits SyntaxWarning for return-in-finally because it silently suppresses in-flight exceptions. Fixes NousResearch#21088

…HOME (NousResearch#35027 regression) (NousResearch#38556) The stage2 hook gates the recursive chown of the build trees under $INSTALL_DIR (.venv, ui-tui, node_modules) so a HERMES_UID/PUID remap leaves them writable by the new runtime UID — needed for lazy_deps 'uv pip install' of platform extras (NousResearch#15012, NousResearch#21100) and the TUI esbuild rebuild into ui-tui/dist (NousResearch#28851). NousResearch#35027 folded that chown under the $HERMES_HOME ownership check ('stat $HERMES_HOME != hermes_uid'). But 'usermod -u <new> hermes' re-chowns the hermes home dir ($HERMES_HOME == /opt/data) to the new UID as a side effect, so after any remap that stat is already satisfied and needs_chown is false — silently skipping the build-tree chown on the common PUID/NAS path. The venv stays owned by the build-time UID (10000), so lazy installs and TUI rebuilds fail with EACCES. Probe the build trees directly instead: chown only when /opt/hermes/.venv is not already owned by the runtime hermes UID. Independent of $HERMES_HOME ownership, idempotent across restarts. Verified live: built the image, booted with HERMES_UID/HERMES_GID on a fresh named volume, confirmed .venv/ui-tui/node_modules end up owned by the remapped UID and 'uv pip install' into the venv succeeds; confirmed the recursive chown fires once and is skipped on restart.

teknium1 · 2026-07-29T01:35:38Z

You were the earliest to fix the return-in-finally restart race — thank you! #73520 merged @brunopirz's #52004 (rebased onto the current _voice_restart_recording_async), with explicit co-credit to you in the PR.

(Landed via #73520, merge e04c2a9ebd.) Closing.

…HOME (NousResearch#35027 regression) (NousResearch#38556) The stage2 hook gates the recursive chown of the build trees under $INSTALL_DIR (.venv, ui-tui, node_modules) so a HERMES_UID/PUID remap leaves them writable by the new runtime UID — needed for lazy_deps 'uv pip install' of platform extras (NousResearch#15012, NousResearch#21100) and the TUI esbuild rebuild into ui-tui/dist (NousResearch#28851). NousResearch#35027 folded that chown under the $HERMES_HOME ownership check ('stat $HERMES_HOME != hermes_uid'). But 'usermod -u <new> hermes' re-chowns the hermes home dir ($HERMES_HOME == /opt/data) to the new UID as a side effect, so after any remap that stat is already satisfied and needs_chown is false — silently skipping the build-tree chown on the common PUID/NAS path. The venv stays owned by the build-time UID (10000), so lazy installs and TUI rebuilds fail with EACCES. Probe the build trees directly instead: chown only when /opt/hermes/.venv is not already owned by the runtime hermes UID. Independent of $HERMES_HOME ownership, idempotent across restarts. Verified live: built the image, booted with HERMES_UID/HERMES_GID on a fresh named volume, confirmed .venv/ui-tui/node_modules end up owned by the remapped UID and 'uv pip install' into the venv succeeds; confirmed the recursive chown fires once and is skipped on restart.

alt-glitch added type/bug Something isn't working comp/cli CLI entry point, hermes_cli/, setup wizard P3 Low — cosmetic, nice to have labels May 7, 2026

alt-glitch mentioned this pull request May 25, 2026

fix(cli): avoid return in voice cleanup finally #32193

Open

benbarclay mentioned this pull request Jun 4, 2026

fix(docker): chown build trees on UID remap independently of $HERMES_HOME (#35027 regression) #38556

Merged

juniorbra mentioned this pull request Jun 11, 2026

fix(docker): re-chown scripts/whatsapp-bridge on UID remap so WhatsApp setup's npm install works #44487

Closed

teknium1 reviewed Jul 12, 2026

View reviewed changes

liuhao1024 force-pushed the fix/issue-21088-return-in-finally-voice branch from ab8f04a to 4d3e294 Compare July 13, 2026 00:10

teknium1 added sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:blast-massive Sweeper blast radius: massive — everyone, every turn (invariant surface) labels Jul 13, 2026

GottZ mentioned this pull request Jul 19, 2026

SyntaxWarning: return in finally block in _voice_process_recording (Python 3.14+) #21088

Closed

This was referenced Jul 28, 2026

fix(voice): CLI/TUI voice mode UX and environment fixes (15 items) #73520

Merged

fix(voice): prevent restart race when continuous mode stops after 3 no-speech cycles #52004

Closed

teknium1 closed this Jul 29, 2026

This was referenced Aug 3, 2026

fix(gateway): report launchd supervision accurately #67744

Open

fix(gateway): query owning systemd manager for drain timing #64029

Draft

Navigation Menu

Uh oh!

fix(voice): remove return-in-finally to fix Python 3.14+ SyntaxWarning - #21100

fix(voice): remove return-in-finally to fix Python 3.14+ SyntaxWarning#21100
liuhao1024 wants to merge 1 commit into
NousResearch:mainfrom
liuhao1024:fix/issue-21088-return-in-finally-voice

liuhao1024 commented May 7, 2026 •

edited

Loading

Uh oh!

teknium1 left a comment

Uh oh!

teknium1 Jul 12, 2026

Uh oh!

teknium1 Jul 12, 2026

Uh oh!

teknium1 commented Jul 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

liuhao1024 commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR do?

Root Cause

Fix

Related Issue

Type of Change

Changes Made

How to Test

Checklist

Code

Documentation & Housekeeping

Uh oh!

teknium1 left a comment

Choose a reason for hiding this comment

Problems

Suggested changes

Uh oh!

teknium1 Jul 12, 2026

Choose a reason for hiding this comment

Uh oh!

teknium1 Jul 12, 2026

Choose a reason for hiding this comment

Uh oh!

teknium1 commented Jul 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

liuhao1024 commented May 7, 2026 •

edited

Loading