Skip to content

fix(title): don't let an unrecognised enabled value silently disable titling - #80382

Open
fabiosiqueira wants to merge 1 commit into
NousResearch:mainfrom
fabiosiqueira:fix/title-enabled-unrecognised-value
Open

fix(title): don't let an unrecognised enabled value silently disable titling#80382
fabiosiqueira wants to merge 1 commit into
NousResearch:mainfrom
fabiosiqueira:fix/title-enabled-unrecognised-value

Conversation

@fabiosiqueira

Copy link
Copy Markdown
Contributor

Follow-up to the auxiliary.title_generation.enabled gate that #66049 landed
(salvaging #37349), for the issue it was fixing: #41744.

The gap

_auto_title_enabled() (agent/title_generator.py:57) reads the knob with
is_truthy_value(title_config.get("enabled"), default=True). That helper answers
"is this truthy?" — the right question for an env var, the wrong one for a config
key whose documented default is on. default=True applies only when the key is
absent (value is None), so every value the truthy set doesn't recognise is
falsy, and the safe direction ends up being a typo in the key, not in the value:

enabled: true    -> True      titling on
enabled: ture    -> 'ture'    titling OFF   <- typo meant to enable, disables instead
enbaled: false   -> None      titling on    <- typo in the key falls through to the default

TRUTHY_STRINGS is {"1", "true", "yes", "on"} (utils.py:19), and YAML parses
an unquoted ture as the string "ture". So a user who mistypes the value while
trying to turn titling on silently loses it, with nothing in the log to say
why — the same failure shape #41744 reported, arriving through the fix for it.
cli-config.yaml.example:634 documents the knob as enabled: true, which is
what makes a value typo plausible in the first place.

The change

Recognise the falsy tokens explicitly and treat anything else as "not a value I
understand": keep the documented default and warn, naming the offending value.
Booleans, the truthy tokens and the falsy tokens all behave exactly as before —
enabled: false, no, off, 0 still disable titling.

Scope

Deliberately at this call site, not in utils.is_truthy_value. The helper is
shared, and env_var_enabled passes default=False, where collapsing
unrecognised into False is correct — the distinction belongs to callers whose
default is True. Seven call sites pass default=True today
(title_generator.py:68, verify_hooks.py:47, cli.py:12762, voice.py:259,
web_routers/tools.py:96, delegate_tool.py:654,
transcription_tools.py:162); this PR fixes the one reported in #41744 rather
than assuming the same answer fits the other six. Happy to follow up on the rest
if you'd like it handled centrally.

Tests

tests/agent/test_title_generator.py — parametrised over recognised truthy
values, recognised falsy values, unrecognised values (asserting titling stays on
and that the warning names the value), and the absent key. The unrecognised
cases fail on current main and pass with the change; the rest pass on both.
32 passed for the file.

— 🤖 Claude Opus 5

@alt-glitch alt-glitch added type/bug Something isn't working P3 Low — cosmetic, nice to have comp/agent Core agent runtime: loop, agent_init, prompt builder, context-compression, responses endpoint area/config Config system, migrations, profiles sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades labels Aug 6, 2026
…titling

`_auto_title_enabled()` reads the knob with
`is_truthy_value(..., default=True)`. That helper answers "is this truthy?",
which is the right question for an env var but the wrong one for a config
key whose documented default is on: `default=True` only applies when the key
is *absent* (`value is None`), so every unrecognised value is falsy.

The result is that the safe direction is a typo in the key, not in the value:

    enabled: true    -> True      titling on
    enabled: ture    -> 'ture'    titling OFF   <- typo meant to enable
    enbaled: false   -> None      titling on    <- typo in the key

A user who mistypes the value while trying to turn titling *on* loses it,
with nothing in the log to say why — the same shape as the original
`enabled` bug from NousResearch#41744, arriving through the fix for it.

Recognise the falsy tokens explicitly and treat anything else as "not a
value I understand": keep the documented default and warn, naming the
offending value. Booleans, the truthy tokens and the falsy tokens all behave
exactly as before.

Scoped to this call site on purpose. `utils.is_truthy_value` is shared —
`env_var_enabled` passes `default=False`, where collapsing unrecognised into
False is correct — so the distinction belongs to the caller that has a
default of True, not to the helper. Seven call sites pass `default=True`
today; this is the one reported in NousResearch#41744.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@fabiosiqueira
fabiosiqueira force-pushed the fix/title-enabled-unrecognised-value branch from 3a4c659 to 6d11a92 Compare August 17, 2026 00:28
fabiosiqueira added a commit to fabiosiqueira/hermes-engine that referenced this pull request Aug 17, 2026
Routine /fork-sync catch-up. Clean merge-tree dry run (0 conflicts,
8 files auto-merged: .gitignore, agent/agent_init.py, agent/curator.py,
cron/scheduler.py, run_agent.py, tools/skill_manager_tool.py,
tools/skill_usage.py, tools/skills_tool.py). Open upstream PRs NousResearch#74875,
NousResearch#80382, NousResearch#78819, NousResearch#45809, NousResearch#27724 re-verified mergeable clean against the
new tip; carry b1e8eb1 (skip_memory_provider) has no upstream route
and stays local per prior audit.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/config Config system, migrations, profiles comp/agent Core agent runtime: loop, agent_init, prompt builder, context-compression, responses endpoint P3 Low — cosmetic, nice to have sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants