The secret scanner flagged this line as containing an API key. Looking at the code, it is just a normal function call that prepares character opinion data for the story engine. There is no password, key, or token on or near this line.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key. The match applies to this repository.
Contextual assessment: The gitleaks generic-api-key match at line 454 of file lands on a call to judgment_view, an internal helper that filters judgment records for a character's scene payload. The line contains only variable names, keyword arguments, and a set-computed subject list; no literal key, token, or secret value is present in the supplied source. The function reads from the local charter record and produces model-prompt data, matching the project's stated purpose of assembling per-character perception slices. The scanner match is a false positive on ordinary Python source text.
Impact: none · Exploitability: unlikely
Developer action: None required. No credential is present in the supplied source at the flagged location.
The scanner flagged a second line as containing a secret. That line is another ordinary function call building character commitment data, with no key or token anywhere in view. This is a false alarm.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key. The match applies to this repository.
Contextual assessment: The second gitleaks generic-api-key match at line 456 lands on a call to commitment_view, another internal helper that selects the commitments a character is party to for the scene payload. Like the adjacent line, the source contains only identifiers and keyword arguments; no secret-looking literal appears in the surrounding window. Both flagged lines sit in a pure data-assembly function that derives per-character slices from the local charter record, consistent with the engine's documented architecture. The matches are false positives on ordinary source text, and no credential exposure is demonstrated.
Impact: none · Exploitability: unlikely
Developer action: None required. The flagged lines contain no credentials; scanner tuning could reduce these generic-rule false positives.
An automated scanner flagged this line as containing a suspicious link. Looking at the actual code, it is just the app talking to its own local server to save and load scene data, which is exactly what this world-editing screen is supposed to do. Nothing is sent anywhere else.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link. The match applies to this repository.
Contextual assessment: The JS-X-Ray 'shady-link' signal at line 1680 points to API-path string construction used by a single-player local front end. The flagged code builds relative URLs for the application's own backend endpoints (chat body station updates, chat attire and world state records), interpolating a chat identifier and a URL-encoded body name. The scheme-relative path format resembles the pattern the scanner flags as suspicious links, but these are same-origin fetch calls to the engine's local FastAPI server, matching the stated purpose of the world browser UI. No cross-origin destination, external network call, obfuscated string assembly, or credential-bearing URL is present anywhere in the supplied context.
Impact: none · Exploitability: unlikely
Developer action: None required. The scanner match reflects ordinary same-origin API calls that are consistent with the project's purpose.
The scanner suggested this file might contain obfuscated (deliberately hidden) code, but the code shown is ordinary, readable settings-menu code with clear comments. There is nothing hidden in it.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.obfuscated-code. The match applies to this repository.
Contextual assessment: The supplied source for this file is plain, heavily commented interface code that builds settings dialogs for the project's local single-player engine. It declares a fallback list of mode names, builds select and input elements via a helper, and issues fetch calls to the project's own local API routes for chat configuration. There is no minification, hex or base64 blob, encoded string, dynamic evaluation, or any other obfuscation indicator; the scanner's own confidence for the signal was low. The data flow consists of reading and writing style, dialogue, and simulation settings on the local server, which matches the project's stated purpose and is visible in the user interface. Nothing in the evidence shows concealed behavior, an external destination, or credential handling.
The automated secret scanner thought it saw an API key on this line, but the line is just normal program code that builds a character's view of the scene. There is no password, key, or credential here, and nothing is sent anywhere.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key. The match applies to this repository.
Contextual assessment: The flagged line is a call to a view-building helper that selects per-character social judgment entries, with a set-difference of locally present character keys and an integer cap. The surrounding function is a scene-slice assembler for the project's single-player fiction engine: it reads only in-memory world-state dictionaries (bodies, minds, politics, judgments, commitments) and returns a structured payload for model prompts. There is no literal resembling a credential, no network destination, no file or environment read, and no attacker-controlled input path anywhere in the supplied context. The generic credential pattern evidently matched the keyword arguments and numeric values of this ordinary function call, which is a classic false positive for generic key detectors on configuration-like code.
This is the same kind of false alarm as the line above: ordinary code that assembles character information, with no key or secret in it.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key. The match applies to this repository.
Contextual assessment: This line is the adjacent call to a commitments-view helper with the same shape: locally held dictionaries, a set of present characters, and an integer cap. It performs no I/O, reads no environment or configuration secrets, and its output feeds the engine's per-presence payload described in the project's documentation. The generic credential rule matched the syntax of the call rather than any credential value; no secret-like material exists in the supplied source window.
The scanner flagged this regular expression as potentially unsafe, but it is a simple pattern that only recognizes a fixed short list of formatting tags. It cannot get stuck looping on tricky input, and it is used only to style story text in the browser.
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 is a small, literal-only regular expression that recognizes a closed allowlist of emphasis tag names, an optional color-name attribute, and closing brackets. It contains no nested quantifiers, no unbounded groups, and no backtracking blowup structure: each alternative is a fixed string, the optional attribute group matches a bounded character class, and the whole expression fails or succeeds in effectively linear time over the input. It is applied to a single turn's prose text, which is bounded in length. The surrounding rendering code deliberately builds DOM nodes rather than parsing HTML, so the pattern also serves the project's stated purpose of rendering a narrow emphasis subset from model output as literal text otherwise. There is no demonstrated denial-of-service path, and even a contrived slowdown on user-supplied prose would at worst be a recoverable local slowdown, which this policy rates as low impact.
Save handler suppresses fetch errors without user feedback
low risk · medium confidence
If something goes wrong while checking or saving the raw record, the screen may stay quiet about it and the user's manual edit can be lost. This is a usability bug, not a security problem.
Technical assessment
The Raw JSON tab's save handler re-reads the current record to detect concurrent edits, and if that re-read fails the failure is swallowed and treated as if the record were unchanged. Similarly, an exception during the subsequent PUT is not caught, so the tab may not surface the failure state to the user. This is a local reliability issue only: the endpoints are same-origin, the failure mode is a confusing or lost manual edit within the user's own single-player session, and no attacker-controlled path or external data flow is involved.
Impact: low · Exploitability: unlikely
Developer action: Distinguish a failed freshness re-read from an unchanged record, and catch and surface PUT errors so the user knows their save did not land.