[21-aakash]

Related issue

Fixes #8888

Summary

Verification

• Tests added or updated for the changed behavior
• Relevant tests and quality checks pass locally

Additional context

---

Note

Low Risk
Small behavioral fix in a search tool constructor and init path; covered by an added unit test.

Overview
Fixes GithubSearchTool so content_types passed at construction are stored on the instance and used when indexing a repo, including when the repo is added later via add() rather than github_repo at init.

Constructor changes: content_types is forwarded into super().__init__ via kwargs so Pydantic keeps the configured list. When a repo is fixed at init, add runs for any github_repo (not only when both repo and content_types are set) and passes self.content_types instead of the raw constructor argument.

A test asserts that a tool built with content_types=["repo"] and no initial repo still passes ["repo"] into the adapter when add(repo=...) is called.

^{Reviewed by Cursor Bugbot for commit c5e037b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[strix-security]

Strix Security Review

✅ No open security findings.

PR summary: This PR fixes `GithubSearchTool` so that `content_types` supplied at construction time is preserved (forwarded through to `RagTool`'s initializer) and used by the eager repo-indexing call instead of being dropped. It also adds a regression test asserting the configured content types reach the adapter metadata.

Review summary

The change is confined to GithubSearchTool.__init__: configured content_types is now forwarded into the pydantic initializer and reused by the eager self.add(...) call instead of gating it. I traced the only consumer of content_types (the GitHub RAG loader, which uses it for plain membership checks against the four known values) and found no interpolation into a command, path, query, or URL, and the repo URL/metadata construction is pre-existing unchanged code. The behavioral effect — indexing the repo even when content_types is left at its default, and pinning content_types to constructor config rather than LLM-supplied arguments — is functional and marginally tighter from a trust standpoint. No security vulnerabilities identified in the changed lines.

_{Review 1 on this PR · c5e037b · requested Nov 1 10:41 UTC when the PR was opened}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}

[github-actions]

Thanks for the pull request.

First-time contributors need an associated open issue before we can review a PR.

1. Open an issue with a template, or pick an existing open one.
2. Open a new PR (or reopen this one) whose title or body mentions that issue, for example #123.

See the contributing guide.