Repository navigation
Lock conflicts keep one side; environment changes beside main; current pixi in CI - #21
Conversation
…t pixi in CI - `.gitattributes`: `pixi.lock merge=binary linguist-language=YAML linguist-generated=true` (pixi's default line, minus `-diff`, so lock diffs stay reviewable). A conflict keeps one side whole instead of writing markers into YAML. - `.claude/settings.json`: `permissions.additionalDirectories: ["../<project>-lock"]`, the checkout beside main where a task changing the environment locks and installs it; worktree sessions copy its lock without a prompt. - CI: `setup-pixi@v0.11.1` with `pixi-version: latest`. pixi 0.60 cannot read lock format v7, which current pixi writes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c151747d01
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "analysis-workflow@quadbio": true | ||
| }, | ||
| "permissions": { | ||
| "additionalDirectories": ["../{{ cookiecutter.project_name }}-lock"], |
There was a problem hiding this comment.
When a session follows the README's claude --worktree flow, Claude stores the worktree under <project-root>/.claude/worktrees/<task> (worktree documentation), and relative permission paths anchor at the session's primary working directory (settings documentation). Consequently, this entry resolves to <project-root>/.claude/worktrees/{{ cookiecutter.project_name }}-lock, not the <parent>/{{ cookiecutter.project_name }}-lock checkout described by the workflow. Environment-changing tasks run from worktrees therefore do not receive access to the actual lock checkout and will still prompt or fail in non-interactive permission modes; derive the path from the main checkout or place the lock checkout at the configured location.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Not changing this: tested. In an interactive claude --worktree <task> session started from the main checkout, /permissions → Workspace listed the entry resolved beside the main checkout (<parent>/<project>-lock), not under .claude/worktrees/, and copying the lock from there ran without a prompt. A headless claude -p run in a fresh worktree does prompt, but that is workspace trust (project additionalDirectories apply only once the folder is trusted), not path resolution.
1 participant
Companion to quadbio/analysis-workflow#12.
.gitattributes:pixi.lock merge=binary linguist-language=YAML linguist-generated=true, pixi's default line minus-diffso lock diffs stay reviewable. A lock conflict keeps one side whole instead of writing conflict markers into the YAML..claude/settings.json:permissions.additionalDirectories: ["../<project>-lock"]. That is the checkout beside main where a task changing the environment locks, installs and tests it, so worktree sessions can copy its lock back without a prompt. From a worktree, the entry resolves beside the main checkout.setup-pixi@v0.11.1withpixi-version: latest, here and in the generated project's workflows. pixi 0.60 can't read lock format v7, which current pixi writes.🤖 Generated with Claude Code