Genie resolves symlinked repo members to realpaths and breaks sibling relative imports

Genie fails when a .genie.ts file is run from a symlinked repo member and that file imports a sibling path such as ../effect-utils/....

Reproduction

https://github.com/schickling-repros/2026-04-effect-utils-genie-symlink-import-bug

nix run .#repro

The repro is fully synthetic and public. It creates a temp layout with:

• linked/repo -> ../real-repo
• linked/effect-utils -> <public effect-utils source>

The .genie.ts file lives in real-repo but imports ../effect-utils/genie/external.ts. That import should work from the logical symlinked layout, but Genie executes the file from its physical realpath instead.

Expected

Genie should preserve the logical --cwd path, or otherwise resolve relative imports in .genie.ts files so sibling paths under the symlinked workspace layout continue to work.

Actual

nix run .#repro deterministically fails with:

GenieImportError: Failed to import .../real-repo/package.json.genie.ts: ResolveMessage: Cannot find module '../effect-utils/genie/external.ts'

The JSON output also shows that Genie's effective cwd is the physical real-repo path rather than the symlinked linked/repo path.

Why this matters

This breaks megarepo-style workspaces where repo members are attached under a logical repos/<name> tree and .genie.ts files intentionally import sibling repos through that logical layout.

Versions

• genie: current github:overengineeringstudio/effect-utils#genie as of 2026-04-13
• Repro observed on macOS arm64
• Repro command verified locally before filing

Filed by an AI assistant on behalf of @schickling

Start by running nix run .#repro and inspect how the .genie.ts file, including package.json.genie.ts, is executed and how its effective cwd is reported. Done means the logical linked/repo cwd is preserved and the sibling ../effect-utils/genie/external.ts import succeeds in the synthetic reproduction.