Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug]: test home guard treats '..name' children of protected trees as outside them

Closed Beginner friendly
  • Is something wrong?
#7,853 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
62/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
testing-qa

Research direction

Start in src/lib/test-home-guard.ts: compare the isInside(parent, child) helper, which uses !rel.startsWith(".."), with isSameOrInsideIgnoringPlatformCase() next to it, which splits on the separator. Reproduce by checking protectedRemovalReason(join(protectedHome, "..backup")) against protectedRemovalReason(join(protectedHome, "backup")). Done when the first returns a refusal, the case-variant equality for OpenCodex and Codex homes is handled on case-insensitive platforms, and the tests cover both.

Written by the indexing model from the issue text.

Description

bug
Client or integration

Other

Area

Other

Summary

src/lib/test-home-guard.ts protects the developer's real OpenCodex, Codex, Claude and LaunchAgents trees from test writes and removals. Its isInside(parent, child) helper, used by protectedRemovalReason() and therefore by assertRemovalOutsideProtectedTrees(), decides containment with !rel.startsWith("..") on the relative path. That is a string-prefix test, not a path-component test. A direct child of a protected tree whose name begins with two dots, such as ~/.opencodex/..backup, has the relative path ..backup. It is therefore judged outside the tree, and the removal guard does not refuse it. The neighbouring isSameOrInsideIgnoringPlatformCase() already does this correctly: it splits on the separator and only treats a leading .. component as leaving the root.

Separately, the equality comparisons for the OpenCodex and Codex homes (canonicalize(dir) === PROTECTED_HOME) are case-sensitive. On Windows and macOS, a not-yet-existing case variant such as .OPENCODEX canonicalizes through its parent and does not compare equal, although the filesystem treats it as the same directory.

Expected: protected-tree containment and equality use component-aware comparison, with case folding on case-insensitive platforms, as the Claude tree checks already do.

Found while reviewing the test-only fixture preload in #7852, which now carries its own component-aware checks.

Reproduction

With the guard armed and a synthetic real home: protectedRemovalReason(join(protectedHome, "..backup")) returns null, while protectedRemovalReason(join(protectedHome, "backup")) refuses.

Version

dev (2.94.0 line)

Operating system

All (case folding: Windows and macOS)

Provider and model

No response

Logs or error output
n/a
Screenshots and supporting files

No response

Redacted configuration
n/a
Checks
  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.
Dominant language
TypeScript
Stars
16.9k
Forks
1.3k
Avg merge
16h 25m
Merged PRs (30d)
706

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lidge-jun/opencodex

All issues in lidge-jun/opencodex

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.