fix: disable SC1091 globally and remove source-path=SCRIPTDIR from .shellcheckrc#2939
Conversation
…hellcheckrc
The source-path=SCRIPTDIR directive was the root cause of exponential memory
expansion when combined with --external-sources (-x). ShellCheck recursively
followed source directives across 460+ scripts, causing 11 GB RSS, kernel
panics, and 73 zombie processes (GH#2915).
source-path=SCRIPTDIR was originally added to suppress SC1091 info-level
warnings, but it only partially worked — 255 of 404 scripts use dynamic
paths (${SCRIPT_DIR}/foo.sh) that ShellCheck cannot resolve regardless.
This commit:
- Removes source-path=SCRIPTDIR from .shellcheckrc
- Adds disable=SC1091 globally (info-level, not a real error)
- Removes -x and -P SCRIPTDIR from linters-local.sh invocations
- Updates comments in pulse-wrapper.sh, shellcheck-wrapper.sh,
memory-pressure-monitor.sh to reflect the new approach
Defense-in-depth layers remain: shellcheck-wrapper.sh strips
--external-sources, SHELLCHECK_PATH routes through wrapper via .zshenv,
per-file timeouts, ulimit -v, and process-guard-helper.sh.
Verified: shellcheck -x completes instantly with no memory expansion
when source-path=SCRIPTDIR is absent from .shellcheckrc.
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a critical memory consumption issue with ShellCheck by refactoring its configuration and invocation parameters. The primary goal is to eliminate exponential memory growth and kernel panics caused by ShellCheck's recursive source following, while also managing the Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request provides a well-reasoned fix for a critical performance issue related to shellcheck's memory consumption. The changes correctly identify and remove the root cause by eliminating source-path=SCRIPTDIR from .shellcheckrc and disabling the SC1091 check globally. The related shellcheck command-line invocations are updated accordingly, and comments across several scripts are modified to accurately document the new strategy. The changes are consistent, targeted, and effectively resolve the described problem. I have reviewed the modifications and have no further feedback.
🔍 Code Quality Report�[0;35m[MONITOR]�[0m Code Review Monitoring Report �[0;34m[INFO]�[0m Latest Quality Status: �[0;34m[INFO]�[0m Recent monitoring activity: 📈 Current Quality Metrics
Generated on: Thu Mar 5 18:35:14 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
|



Summary
source-path=SCRIPTDIRfrom.shellcheckrc— the root cause of exponential memory expansion (11 GB RSS, kernel panics, 73 zombie processes) when combined with--external-sources(-x)disable=SC1091globally — SC1091 is an info-level hint that ShellCheck cannot follow a sourced file, not a real error. 255 of 404 scripts use dynamic paths (${SCRIPT_DIR}/foo.sh) that ShellCheck cannot resolve regardless-xand-P SCRIPTDIRflags fromlinters-local.shshellcheck invocationspulse-wrapper.sh,shellcheck-wrapper.sh,memory-pressure-monitor.shWhy
The previous fix for SC1091 noise (PR #2427, t1344) added
source-path=SCRIPTDIRto.shellcheckrc. This solved a cosmetic problem (info-level warnings) but created a catastrophic one: when bash-language-server hardcodes--external-sources, ShellCheck recursively follows source directives across 460+ scripts, causing exponential memory growth.Multiple defense-in-depth layers were added (PR #2885, #2918, #2923, #2937) to contain the damage — but the root cause remained in
.shellcheckrc. This PR removes it.Defense-in-depth layers (all remain active)
shellcheck-wrapper.shstrips--external-sourcesfrom bash-language-server invocationsSHELLCHECK_PATHin.zshenvroutes through the wrapper for non-interactive shellslinters-local.shulimit -v(1 GB) caps virtual memory per shellcheck subprocessprocess-guard-helper.shkills shellcheck processes exceeding 512 MB RSSpulse-wrapper.shuses--norcfor quality sweepsVerified
shellcheck -xcompletes instantly with no memory expansion whensource-path=SCRIPTDIRis absentshellcheckandbash -nsyntax checkRelated
Closes #2915
Previous fixes in the incident chain:
Note: The upstream hazard remains for other opencode/shellcheck users. See anomalyco/opencode#16209 for the suggested upstream fix.