Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix [Bug]: skill_view ignores HERMES_SESSION_PLATFORM when checking disabled skills [1 pull requests]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

Bug Description

skill_view() can expose a skill that is disabled for the active gateway session platform because _is_skill_disabled() ignores HERMES_SESSION_PLATFORM task-local context.

Fix Action

Fixed

PR fix notes

PR #13085: fix(tools): honor HERMES_SESSION_PLATFORM in skill_view (#13027)

Description (problem / solution / changelog)

Problem

skill_view() can expose a skill that is disabled for the active gateway-session platform because _is_skill_disabled() ignores the HERMES_SESSION_PLATFORM task-local context. Every other disabled-skill caller (see agent/skill_utils.py:148-160) already resolves session context via get_session_env('HERMES_SESSION_PLATFORM'), so a Discord session that marks a skill as platform_disabled can still open it through skill_view.

Fixes #13027.

Fix

_is_skill_disabled() now delegates to agent.skill_utils.get_disabled_skill_names(platform=...), which already resolves platform in this order: explicit arg → HERMES_PLATFORM → HERMES_SESSION_PLATFORM. As a bonus the delegate also applies _normalize_string_set, so scalar/null YAML values no longer slip through. The call site in skill_view (line 1000) is unchanged.

Test plan

  • Added test_session_platform_honored regression test that reproduces the issue body's scenario end-to-end
  • Reworked existing TestIsSkillDisabled tests to patch the new delegate path (agent.skill_utils.get_disabled_skill_names) instead of the removed hermes_cli.config.load_config mock
  • pytest tests/hermes_cli/test_skills_config.py tests/tools/test_skills_tool.py — 101 passed
  • Reran the shell repro from the issue on the fixed branch — skill_view('blocked-skill') now returns success: false, error: "Skill '...' is disabled..." under set_session_vars(platform='discord'); without session context the skill is still visible (no regression on the default path)

Changed files

  • tests/hermes_cli/test_skills_config.py (modified, +55/-34)
  • tools/skills_tool.py (modified, +8/-11)

Code Example

tmp=$(mktemp -d)
mkdir -p "$tmp/skills/blocked-skill"
cat > "$tmp/config.yaml" <<'YAML'
skills:
  platform_disabled:
    discord: [blocked-skill]
YAML
cat > "$tmp/skills/blocked-skill/SKILL.md" <<'MD'
---
name: blocked-skill
description: blocked
---
blocked
MD
source venv/bin/activate && HERMES_HOME="$tmp" python - <<'PY'
from gateway.session_context import set_session_vars, clear_session_vars
from tools.skills_tool import skill_view
import os
os.environ.pop('HERMES_PLATFORM', None)
tokens = set_session_vars(platform='discord')
try:
    print(skill_view('blocked-skill'))
finally:
    clear_session_vars(tokens)
PY

---

{"success": true, "name": "blocked-skill", "readiness_status": "available", ...}
RAW_BUFFERClick to expand / collapse

Bug Description

skill_view() can expose a skill that is disabled for the active gateway session platform because _is_skill_disabled() ignores HERMES_SESSION_PLATFORM task-local context.

Affected code:

  • tools/skills_tool.py:496-508
  • tools/skills_tool.py:847-849
  • comparison: agent/skill_utils.py:148-160 already resolves platform from get_session_env('HERMES_SESSION_PLATFORM')

Minimal Reproduction

tmp=$(mktemp -d)
mkdir -p "$tmp/skills/blocked-skill"
cat > "$tmp/config.yaml" <<'YAML'
skills:
  platform_disabled:
    discord: [blocked-skill]
YAML
cat > "$tmp/skills/blocked-skill/SKILL.md" <<'MD'
---
name: blocked-skill
description: blocked
---
blocked
MD
source venv/bin/activate && HERMES_HOME="$tmp" python - <<'PY'
from gateway.session_context import set_session_vars, clear_session_vars
from tools.skills_tool import skill_view
import os
os.environ.pop('HERMES_PLATFORM', None)
tokens = set_session_vars(platform='discord')
try:
    print(skill_view('blocked-skill'))
finally:
    clear_session_vars(tokens)
PY

Observed:

{"success": true, "name": "blocked-skill", "readiness_status": "available", ...}

Expected Behavior

When a Discord session marks a skill as platform-disabled, skill_view() should reject it just like other skill-resolution paths do.

Actual Behavior

The skill is still viewable because _is_skill_disabled() only checks the explicit platform arg or os.getenv('HERMES_PLATFORM').

Suggested Investigation Direction

Make _is_skill_disabled() share the same platform-resolution path as agent.skill_utils.get_disabled_skill_names(), including session context.

extent analysis

TL;DR

Modify the _is_skill_disabled() function to consider the HERMES_SESSION_PLATFORM task-local context, similar to agent/skill_utils.py:148-160, to correctly determine skill availability based on the active gateway session platform.

Guidance

  • Review the tools/skills_tool.py file, specifically lines 496-508 and 847-849, to understand the current implementation of _is_skill_disabled().
  • Update _is_skill_disabled() to resolve the platform from get_session_env('HERMES_SESSION_PLATFORM'), following the example in agent/skill_utils.py:148-160.
  • Verify the change by re-running the minimal reproduction script and checking that the expected behavior is observed, i.e., the skill is not viewable when marked as platform-disabled for the Discord session.
  • Consider adding tests to ensure the correctness of the _is_skill_disabled() function across different platforms and session contexts.

Example

def _is_skill_disabled(skill_name, platform=None):
    # Resolve platform from session context if not explicitly provided
    if platform is None:
        platform = get_session_env('HERMES_SESSION_PLATFORM')
    # ... rest of the function implementation ...

Notes

This solution assumes that the get_session_env function is correctly implemented and returns the expected value for HERMES_SESSION_PLATFORM. Additionally, this change may have implications for other parts of the codebase that rely on the current behavior of _is_skill_disabled().

Recommendation

Apply the workaround by modifying the _is_skill_disabled() function to consider the session context, as this will correctly implement the expected behavior for skill resolution based on the active gateway session platform.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#docker error#permission error#memory optimization#batch processing#GPU compatibility

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - ✅(Solved) Fix [Bug]: skill_view ignores HERMES_SESSION_PLATFORM when checking disabled skills [1 pull requests]