This build tool uses a risky JavaScript command to read a list of error codes from another file in the same project. Because it only reads files already included in the project and does not accept outside input, the actual danger is very low, though using a safer reading method would be better practice.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The script uses eval to parse an object literal extracted from a sibling committed file within the repository. The input to eval is not user-controlled, network-sourced, or externally supplied at runtime; it is read from a local tooling file. While eval is a discouraged pattern, the data flow is constrained to local repository contents, making exploitation unlikely.
Impact: low · Exploitability: unlikely
Developer action: Replace eval with a safer parsing method such as JSON.parse or a dedicated parser if the source file format permits.
Credential access and network transmission in one file
Expected behavior · high confidence
This is a standard Docker health check that pings the app's own local health endpoint to see if it is running. It only reads the port number from the environment, not any passwords or secrets, and the request goes to the same machine. There is no credential theft or data exfiltration here.
Technical evidence
Scanner reason: A credential source and an outbound network operation were detected in the same file.
Contextual assessment: The flagged line is a Docker HEALTHCHECK command that reads only process.env.PORT (defaulting to 6633) and performs an HTTP fetch to 127.0.0.1 on the /health endpoint. No credential environment variables (such as JWT_SECRET) are accessed. The network destination is localhost, which is the container's own service. This is a standard container health-check pattern and does not exfiltrate any data.
Credential access and network transmission in one file
Expected behavior · high confidence
This code sends your lorebook (world info) settings to the app's own server so they can be saved. It does not send any passwords or API keys. The alert was triggered because the file mentions API keys elsewhere and also makes a network request, but this specific request only carries settings data.
Technical evidence
Scanner reason: A credential source and an outbound network operation were detected in the same file.
Contextual assessment: The flagged fetch at line 693 is inside patchGlobalLorebookToServer and sends a lorebook settings patch to the same-origin endpoint /api/user-preferences. The request body contains only lorebook configuration fields. No API key, credential, or secret material is read or included in the payload. The scanner matched because the file imports useApiKeysStore and also contains a network call, but the actual data flow at this location does not transmit credentials.
This code runs user-defined find-and-replace rules in a small isolated environment with a strict time limit, so a badly written or malicious regex cannot freeze the app. The user's regex text is passed in as data, not stitched into the program, so it cannot run arbitrary commands. This is a protective measure, not a dangerous one.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The matched runInNewContext call executes a fixed, non-interpolated script that constructs a RegExp from already-validated source and flags, then performs a String.replace. The user-controlled values (pattern, flags, text, replacement) are passed as sandbox context data, not spliced into the script string, so there is no code injection path. The VM context is used specifically to obtain a timeout capability for regex execution, defending against ReDoS from user-defined regex rules. While node:vm is not a true security sandbox, the code is not relying on it for untrusted-code isolation; it is relying on it for timeout enforcement. No network, filesystem, credential, or persistence operations are present.
Credential access and network transmission in one file
Expected behavior · high confidence
This file handles login tokens for the app. It saves tokens in the browser and sends them only to the app's own server addresses (like /api/auth/me) to prove who you are when making requests. Nothing is sent to outside websites. This is normal login behavior.
Technical evidence
Scanner reason: A credential source and an outbound network operation were detected in the same file.
Contextual assessment: This file is a Pinia auth store that persists JWT and refresh tokens in localStorage and sends them to same-origin relative API endpoints (/api/auth/status, /api/auth/refresh, /api/auth/me). The flagged line 127 is a credential-free status check. The credential-bearing calls (refreshSession at line 145, fetchMe at line 161) transmit tokens only to the application's own backend via relative paths. No third-party destinations, no obfuscation, and the data flow is proportional to the stated authentication purpose of a local AI chat app.