macOS: a path that differs only in letter case from the workspace root is flagged as outside the workspace
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 78/100
- Issue-Typ
- Bug
- Klarheit
- Klar beschrieben
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- node.js, typescript
Rechercherichtung
Beginne in src/permissions/workspace.ts damit, getCanonicalPath, canonicalizeForLookup und isWithinRoot nachzuverfolgen; untersuche anschließend den allowExternalDirectory-Zweig und formatOutsideWorkspaceMessage in der Berechtigungs-Engine. Reproduziere den Pfad mit unterschiedlicher Groß-/Kleinschreibung auf macOS und ergänze die vorgeschlagene Unit-Test-Abdeckung: Ein vorhandener Workspace-Pfad mit unterschiedlicher Groß-/Kleinschreibung sollte innerhalb liegen, während ein tatsächlich externer Pfad außerhalb bleibt und keinen doppelten zulässigen Root erstellt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Summary
On macOS (case-insensitive filesystem), a file tool call whose absolute path differs only in
letter case from the workspace root is treated as outside the workspace and raises the
external-directory prompt, even though the path resolves to a file inside the project. Every
occurrence costs a human approval, and approving one grants the case-variant directory, so the
session root set slowly accumulates duplicates of the real root (visible in the prompt's
allowed: list).
Expected Behavior
A path that names an existing file inside the workspace — regardless of letter case, on a
case-insensitive volume — should be recognized as inside the workspace: no external-directory
prompt, no directory grant.
Actual Behavior
Workspace root /Users/dev/Projects/my-app (capital P, macOS). A grep call for
/Users/dev/projects/my-app/apps/web/README.md (lowercase projects) triggers:
Allow Command Code to use GREP on this file?
This action accesses a path outside the current project.
/Users/dev/projects/my-app/apps/web/README.md is outside workspace
(allowed: /Users/dev/Projects/my-app, /Users/dev/.commandcode, /tmp, /private/tmp, /var/folders, …)
Both spellings resolve to the same inode.
Steps to reproduce the issue
- On macOS, start a session in a workspace whose absolute path contains at least one uppercase
letter, e.g./Users/dev/Projects/my-app. - Trigger a file tool call on the same path spelled in lowercase (this happens organically
because the model occasionally re-types absolute paths instead of copying them):grepwithpath: "/Users/dev/projects/my-app/apps/web/README.md", orread_file/edit_filewith the same lowercased path.
- The external-directory gate fires (
risk: { kind: "outside-workspace" }) and the call waits
for human approval. - Approving grants the lowercased directory, so the allowed-roots list grows with case-variant
entries that duplicate the real root.
Root cause
src/permissions/workspace.ts (bundled in @commandcode/harness):
function getCanonicalPath(dirPath: string) {
try {
return process.platform === 'win32' ? fs.realpathSync.native(dirPath) : fs.realpathSync(dirPath);
} catch {
return path.normalize(dirPath);
}
}
canonicalizeForLookup() feeds this into isWithinRoot(), which decides containment with
path.relative(canonicalRoot, canonicalPath) — a case-sensitive string comparison.
On darwin, fs.realpathSync (the JS implementation — .native is only used for win32)
preserves the case of the input for every component that is not a symlink, so a lowercased path
stays lowercased. The native variant goes through libuv's uv_fs_realpath → realpath(3) and
returns the on-disk spelling.
Reproduction without Command Code (Node on macOS):
$ node -e 'const fs=require("fs"),path=require("path");const p="/users/dev/projects/my-app/apps/web/README.md";
console.log("js ", fs.realpathSync(p));
console.log("native", fs.realpathSync.native(p));
console.log("rel ", path.relative("/Users/dev/Projects/my-app", p));'
js /users/dev/projects/my-app/apps/web/README.md
native /Users/dev/Projects/my-app/apps/web/README.md
rel ../../../../users/dev/projects/my-app/apps/web/README.md # → isWithinRoot() === false
Notes: no user-side config fully fixes this
deny/askrule matching already folds case on macOS/Windows, but the workspace boundary does not.- The external-directory gate runs before the allow rules, so an
allowrule cannot silence it. permissions.additionalDirectoriesis the only workaround, and it is itself case-sensitive —
one entry per observed case variant.- Mods cannot help either:
cmd.hooks.beforeToolCallruns afterpermissions.check.
Suggested fix
Use the native realpath wherever it exists, or fold case only when the volume is
case-insensitive:
return fs.realpathSync.native?.(dirPath) ?? fs.realpathSync(dirPath);
The requirement is that two spellings of the same existing path land on the same side of the
workspace boundary.
Command Code Version
1.53.1
Operating System
macOS
Additional context
- macOS 27.0 (APFS, case-insensitive), Node v24.19.0, Command Code 1.53.1.
- Code locations:
getCanonicalPath/canonicalizeForLookup/isWithinRootin
src/permissions/workspace.ts; the gate is theallowExternalDirectorybranch of the
permission engine (risk: { kind: 'outside-workspace' }, message built by
formatOutsideWorkspaceMessage). - A fix would also keep the prompt's
allowed:list clean: today it mixes both spellings of the
same directory once a case-variant path has been approved.
Fix prompt (optional)
In the harness permission engine, make workspace containment case-insensitive for existing paths
on case-insensitive volumes: getCanonicalPath should call fs.realpathSync.native whenever it
is available (not only on win32), so /users/dev/projects/my-app/... canonicalizes to
/Users/dev/Projects/my-app/.... Add a unit test asserting that a case-variant spelling of an
existing workspace path returns isPathInWorkspace() === true, while a genuinely external path
still returns false.
- Vorherrschende Sprache
- Keine Sprachdaten
- Sterne
- 4k
- Forks
- 350
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus CommandCodeAI/command-code
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
CommandCodeAI/command-code#855 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
CommandCodeAI/command-code#841 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
CommandCodeAI/command-code#655 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
CommandCodeAI/command-code#608 ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 70/100
CommandCodeAI/command-code#893 ·
Alle Issues in CommandCodeAI/command-code
Ähnliche Issues
-
P3 tool/tts type/bug
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
NousResearch/hermes-agent#117794 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 86/100
kwakseongjae/auto-hwp#319 ·
-
area:cli bug filter-quality good first issue priority:medium
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
AvengeMedia/DankMaterialShell#3523 ·