Skip to content

fix: skip containerd mountinfo marker on WSL2 to avoid false-positive… - #51968

Open
Ulaganathan-K-B wants to merge 1 commit into
NousResearch:mainfrom
Ulaganathan-K-B:fix/wsl-container-mountinfo-false-positive
Open

fix: skip containerd mountinfo marker on WSL2 to avoid false-positive…#51968
Ulaganathan-K-B wants to merge 1 commit into
NousResearch:mainfrom
Ulaganathan-K-B:fix/wsl-container-mountinfo-false-positive

Conversation

@Ulaganathan-K-B

Copy link
Copy Markdown

… container detection

On WSL2 with Docker Desktop, the WSL2 kernel's /proc/self/mountinfo contains containerd entries even when running natively (not inside any container). The is_container() cgroup-v2 fallback scanned mountinfo for 'containerd' as a marker, producing false positives.

Real containers inside WSL are still detected via /.dockerenv, KUBERNETES_SERVICE_HOST, and /proc/1/cgroup checks earlier in the chain. On WSL, only kubepods/crio markers in mountinfo indicate a real container.

Fixes #51935

What does this PR do?

Related Issue

Fixes #

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 🔒 Security fix
  • 📝 Documentation update
  • ✅ Tests (adding or improving test coverage)
  • ♻️ Refactor (no behavior change)
  • 🎯 New skill (bundled or hub)

Changes Made

How to Test

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:

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

For New Skills

  • This skill is broadly useful to most users (if bundled) — see Contributing Guide
  • SKILL.md follows the standard format (frontmatter, trigger conditions, steps, pitfalls)
  • No external dependencies that aren't already available (prefer stdlib, curl, existing Hermes tools)
  • I've tested the skill end-to-end: hermes --toolsets skills -q "Use the X skill to do Y"

Screenshots / Logs

… container detection

On WSL2 with Docker Desktop, the WSL2 kernel's /proc/self/mountinfo
contains containerd entries even when running natively (not inside any
container). The is_container() cgroup-v2 fallback scanned mountinfo for
'containerd' as a marker, producing false positives.

Real containers inside WSL are still detected via /.dockerenv,
KUBERNETES_SERVICE_HOST, and /proc/1/cgroup checks earlier in the chain.
On WSL, only kubepods/crio markers in mountinfo indicate a real container.

Fixes NousResearch#51935
@alt-glitch alt-glitch added type/bug Something isn't working comp/cli CLI entry point, hermes_cli/, setup wizard platform/windows Native Windows-specific behavior or breakage sweeper:risk-platform-windows Sweeper risk: may break or behave differently on native Windows P2 Medium — degraded but workaround exists duplicate This issue or pull request already exists labels Jun 24, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

This was generated by AI during triage.

Duplicate of #51935 — same is_container() WSL2 false-positive (Docker Desktop mounts containerd into the WSL2 kernel) fixed via the same mechanism (is_wsl() early-return that skips the containerd marker while keeping kubepods/crio). #51935 (by @luxles) was opened ~50 min earlier and is the canonical fix; cross-linking here for the maintainer to pick one.

@teknium1

Copy link
Copy Markdown
Contributor

Thanks for preserving the existing Kubernetes/CRI mountinfo signals while addressing the WSL-specific false-positive path. Current main still returns True for a containerd match in the final mountinfo fallback (hermes_constants.py:945-949), and the PR limits the WSL exception to that marker while adding regression coverage for both the negative containerd case and positive kubepods case.

The discussion-linked #51935 is not an equivalent implementation: its diff returns before inspecting any WSL mountinfo markers, whereas this PR retains kubepods/crio detection.

Automated hermes-sweeper review.

@teknium1 teknium1 added sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform labels Jul 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/cli CLI entry point, hermes_cli/, setup wizard duplicate This issue or pull request already exists P2 Medium — degraded but workaround exists platform/windows Native Windows-specific behavior or breakage sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:risk-platform-windows Sweeper risk: may break or behave differently on native Windows type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants