Repository navigation
doctor --target-dir accepts relative paths while install refuses them as invalid_target #372
Description
Found during the manual verification of the directory-target mode (#363, check 4 observations), alongside #367.
Problem
cortex install --target-dir <relative-existing-dir> refuses relative paths with error=invalid_target (fixed by #369). But cortex doctor --target-dir agent-skills-rel accepts the same relative path and reports ownership=unowned, exit 0. The two commands disagree on what a valid target is, and doctor's report for a relative path is ambiguous about which directory was actually inspected.
Expected direction
Share one target validation between install, doctor (and update/uninstall where applicable): a target that install would refuse as invalid_target should be refused the same way by every command that consumes --target-dir, so the directory-target contract stays consistent across the CLI.
Activity
barbatdev commentedon Oct 23, 2026
Fleet issue review (glm)
Recommendation: approve
Clear, concrete inconsistency between install and doctor target validation, with an exact expected direction (share one validation across every command consuming --target-dir) that is directly testable per command. No file paths are named, so nothing to verify upstream; the criterion is verifiable behaviorally without naming code. Single coherent deliverable, no open questions.
Juan merges; the fleet applies the
status:approvedlabel when a review recommendsapprove.barbatjuan commentedon Oct 23, 2026
I'd like to take this one too. It came out of the same #363 verification, and since #369 already put the
invalid_targetcheck in front of install, the natural fix is to route doctor (and update/uninstall) through that same validation instead of adding a second one.Plan: reuse the target validation from #369 in every command that consumes
--target-dir, add one test per command proving a relative path is refused witherror=invalid_targetand exit 64 without writes, and keep the existing absolute-path behavior pinned. Until #370 lands I'll verify on linux in a container.Could you assign it to me? Happy to step back if you already have it in flight.
barbatdev commentedon Oct 23, 2026
Assigned to you, and the issue is approved. Reusing the invalid_target validation that #369 put in front of install is exactly the right shape; one refusal test per consuming command (error=invalid_target, exit 64, no writes) is the acceptance bar. Open a PR off main referencing this issue (issue-first; Fixes #372 on its own line in the PR body, the CI validates that format) and we review from there.
fix(cli): validate an empty --target-dir instead of falling back
docs(cli): note that usage errors precede the --target-dir check (Refs …
test(cli): pin trailing separators, the empty runtime, and a valid ta…