Repository navigation
fix(init): Tirith integration is detect-only — do NOT modify shell rc - #5
Merged
Merged
Conversation
PR #2 (feat/init-chains-tirith, commit 6f65f9d) appended an `eval "$(tirith init --shell <shell>)"` block to the user's `.bashrc`/`.zshrc`/`config.fish`. That was the wrong design: the ContextCrawler Tirith integration lives at the Claude Code rewrite gate (`hooks/tirith_gate.rs` calls `tirith check` as a subprocess right before auto-allowing a rewrite). The user's interactive shell is not part of the gate's value path and should not be modified by `contextcrawler init -g`. This change: * Replaces `install_tirith_shell_hook` with `report_tirith_status`. Tirith presence is detected; no filesystem write happens outside `~/.claude/`. * Removes the helpers that only existed for the rc-write path: `detect_shell`, `shell_rc_path`, `rc_has_tirith_sentinel`, `build_tirith_block`, and the `TIRITH_SENTINEL_{START,END}` constants. * Drops the 5 unit tests for those removed helpers; keeps a single smoke test (`test_report_tirith_status_never_panics`) covering the remaining surface. * Sentinel comments updated to document the design choice explicitly so it doesn't get re-introduced. Output after `contextcrawler init -g` is now one of: Tirith gate: ARMED — Claude Code rewrites pass through `tirith check` before auto-allow (subprocess invocation only). or Tirith gate: fail-open (binary not on PATH) Optional URL-security defense-in-depth: cargo install tirith No shell config is modified by ContextCrawler either way. Verified: cargo test → 1785 passed / 0 failed / 6 ignored. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
thehoff
added a commit
that referenced
this pull request
Jun 5, 2026
A failed `go build` whose stderr matched none of the error heuristics printed "Go build: Success" while the runner correctly propagated the non-zero exit code — a user-facing message that contradicted reality. Adapt upstream rtk-ai/rtk f69ad6e to the fork: - runner: add `FilteredWithExit` RunMode + `run_filtered_with_exit`, handing the filter the child's exit code. Both filter modes share a new `run_captured_filter` helper that keeps the fork-only no-bloat guard (issue #95) and verbatim exit-code propagation (RTK rule #5). - go_cmd: split `filter_go_build` into an exit-aware `filter_go_build_with_exit`. With no recognised error line it now emits "Go build: Success" only on exit 0, otherwise a neutral "Go build: failed (exit N)" message that surfaces the raw output. The exit-blind `filter_go_build` is retained as a thin wrapper (exit 0) for existing callers/tests. Recognised-error path unchanged. Exit-code propagation itself is untouched. Tests: success (exit 0) -> "Success"; failed build (non-zero exit) with no recognised error line -> failure message, never "Success"; failed build with recognised error lines -> errors shown as before. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Reverts the shell-rc-write behavior introduced in PR #2 (commit 6f65f9d).
PR #2's `install_tirith_shell_hook` appended an `eval "$(tirith init --shell )"` block to the user's `.bashrc`/`.zshrc`/`config.fish`. That was the wrong design call on my part — the ContextCrawler Tirith integration lives at the Claude Code rewrite gate (`hooks/tirith_gate.rs` calls `tirith check` as a subprocess right before auto-allowing a rewrite). The user's interactive shell isn't part of the gate's value path and must not be modified by `contextcrawler init -g`.
What changed
New output
When Tirith is installed:
```
Tirith gate: ARMED — Claude Code rewrites pass through `tirith check`
before auto-allow (subprocess invocation only).
```
When Tirith is not installed:
```
Tirith gate: fail-open (binary not on PATH)
Optional URL-security defense-in-depth:
cargo install tirith
No shell config is modified by ContextCrawler either way.
```
Test plan
🤖 Generated with Claude Code