The scanner saw a link with a special 'javascript' address and flagged it. In reality these are just styled click targets for 'remove rule' and 'add rule' buttons in the extension's editor. Clicking them only edits the canvas's own settings on your device; nothing is sent anywhere and nothing harmful happens.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link. The match applies to this repository.
Contextual assessment: The scanner flagged a fixed 'shady-link' signal at line 3006 (and a duplicate at 3013). The matched literal is the string 'javascript:void(0)' assigned as the href of anchor elements used as click buttons ('remove this rule', '+ another rule for this output'). The anchors' click handlers perform local, in-memory list operations on the extension's own configuration data (splicing conditions, pushing new rule objects) followed by a UI redraw. No network request, navigation, or data exfiltration is triggered by these hrefs; javascript:void(0) is a common no-op placeholder so anchor elements behave like buttons. This is a false positive of the static heuristic, not actual network access.
The scanner saw a web address in the code and flagged it. That address is just the official name a browser needs when drawing charts with vector graphics; the code uses it as an identifier when creating chart elements, never as a destination to contact. Nothing is downloaded and no data is sent anywhere.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link. The match applies to this repository.
Contextual assessment: The flagged literal on line 29 is the standard W3C SVG namespace identifier, used solely as the namespace argument to document.createElementNS when the State editor builds its chart graphics. It is not fetched, not loaded as a script, and produces no network traffic. The supplied source shows the module constructing DOM elements and chart visuals locally with no outbound requests. The scanner's shady-link signal is a false positive on a namespace constant.
The scanner saw a web address in the code and flagged it. It is the official identifier the browser requires to draw vector graphics; the program uses it as a label when creating drawing elements, not as a place to fetch anything from. Nothing is downloaded and nothing leaves your machine.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link. The match applies to this repository.
Contextual assessment: The flagged literal on line 20 is the standard W3C SVG namespace identifier required by document.createElementNS to construct SVG elements. It is used only as a namespace argument when building the canvas wire layer; it is never fetched, never used to load a script, and no network request originates from it. The scanner's shady-link heuristic misidentified a namespace constant as a suspicious link. No network access, exfiltration, or external code loading is demonstrated anywhere in the supplied context.
The scanner flagged a link that uses a javascript: address, which can sound alarming. Here it is a hardcoded, empty placeholder used to make a 'Show all' text look like a clickable link; the real behavior is a local click handler that expands text on the page. No code is injected, nothing leaves the browser, and the string is fixed in the source rather than coming from chat content or any untrusted source.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link. The match applies to this repository.
Contextual assessment: The flagged literal is a static, empty javascript: URI assigned to an anchor's href so it renders as a clickable 'Show all' control inside the extension's prompt-inspector UI. The URI is a constant string in the shipped code, not derived from model output, chat content, or any untrusted input, so it cannot be used to execute attacker-chosen script. The attached click handler calls preventDefault and replaces clipped text with the full text locally; there is no navigation, no network request, and no data leaving the page. All message content in this UI path is rendered via textContent, not innerHTML, except for two hardcoded icon fragments, so model-generated content is not interpreted as markup. The scanner rule is a keyword heuristic on the javascript: scheme and does not demonstrate exposure in this data flow.
Impact: none · Exploitability: unlikely
Developer action: Optional cleanup: replace the anchor with a styled button element (or set role/tabindex on a span) and drop the javascript: URI entirely; this avoids tripping strict Content-Security-Policy configurations that forbid javascript: navigation and removes the scanner signal.
A code scanner warned about potentially problematic pattern matching in this file. The patterns in question are used to recognize color values like hex codes and rgba() so the extension can apply its themes. They run on short color strings and cannot lock up or harm anything, so this is a harmless false alarm.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-regex. The match applies to this repository.
Contextual assessment: The scanner flagged the regular expressions in the color-parsing helper. These are fixed, anchored patterns that match short CSS color strings (three- or six-digit hex, optional alpha, and a bounded rgba/rgb functional form). They contain no nested unbounded quantifiers capable of catastrophic backtracking, and the inputs are theme color values (preset constants, user-picked colors, or computed style values) that are short by nature. The file's data flow is entirely local: parsed colors feed theme application, contrast adjustment, and styling of the extension's own UI. No network destination, credential access, obfuscation, or persistence beyond saving theme preferences is present. The scanner signal is a static heuristic about regex construction, not a demonstrated execution or timing problem.
The scanner flagged a text-matching pattern it thought could be slow or dangerous. The pattern is a simple, short one that only recognizes numbers like 3 or 2.5 in user formulas; it cannot loop excessively or hang the app. The file also avoids using JavaScript's eval command on purpose, checking formulas with its own safe interpreter instead.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-regex. The match applies to this repository.
Contextual assessment: The flagged pattern on line 35 is a small linear regex used to tokenize numeric literals in the extension's hand-rolled formula language. It contains no nested or overlapping quantifiers, so it cannot exhibit catastrophic backtracking (ReDoS); matching is bounded by input length. More broadly, the module deliberately implements a recursive-descent parser and evaluator instead of eval, restricting formulas to whitelisted functions and caller-supplied variables. The scanner's unsafe-regex heuristic is a false positive on a well-formed tokenizer pattern, and no denial-of-service or injection path is demonstrated.
A second 'add rule' link uses the same harmless placeholder address. Both links only edit the extension's own settings when clicked. Using regular buttons instead would stop the scanner from complaining, but nothing is wrong either way.
Technical assessment
The same literal 'javascript:void(0)' is also assigned to the '+ another rule' anchor at line 3013, explaining the scanner's second occurrence. Both anchors have click listeners that mutate only the extension's local node configuration and re-render the UI. Replacing these with real button elements would remove the static-analysis noise but is a style choice, not a security fix.