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.
A scanner suggested this file might contain deliberately hidden or scrambled code. The opposite is true: the file is ordinary, clearly written settings-menu code with extensive plain-language comments. Nothing is hidden or disguised.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.obfuscated-code. The match applies to this repository.
Contextual assessment: The obfuscation signal fires on line 1, but the supplied file is plainly readable, heavily commented source for settings dialogs in a browser UI. It defines a fallback list of simulation mode names, a small query-string helper, and modal-building code using standard DOM element creation. There are no hex-encoded strings, packed eval-style payloads, encoded identifiers, or concealed control flow anywhere in the supplied context; the scanner's low confidence is consistent with a heuristic false positive on readable code. The code makes local API calls to the project's own server routes only, matching the stated purpose of a local single-player engine.
An automated scanner thought it found a leaked password or API key on this line, but the actual code there is just normal program logic describing game characters. There is no password, key, or secret anywhere in the shown code.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key. The match applies to this repository.
Contextual assessment: The scanner flagged line 454 as a generic credential match, but the supplied source at that location is an ordinary Python call building a per-character view of social judgments from in-memory simulation state. No secret literal, key-like string, network destination, or credential handling appears anywhere in the surrounding function. The code operates on local simulation data (perceptions, commitments, decisions) and returns a dictionary payload; there is no I/O, external call, or persistence of anything resembling a credential. The rule appears to have matched a keyword pattern such as a parameter named in a way resembling 'key', which is a false positive.
The scanner flagged a second nearby line as a possible leaked key, but that line is also just normal game-engine code listing a character's promises. No secret or credential is present.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key. The match applies to this repository.
Contextual assessment: The second scanner match targets line 456, which in the supplied source is another ordinary Python call selecting a character's commitments from local simulation state. Like the adjacent flagged line, it involves only in-memory dictionary reads and a capped view construction, with no secret material, encoded value, environment access, network call, or file write. The generic pattern evidently keyed on naming conventions within the call arguments rather than any actual credential. The full surrounding function shows a self-contained simulation-state projection with no data leaving the process.
A code scanner flagged this pattern as potentially 'unsafe', but it is a simple, tightly written search for a few formatting tags like bold and italic in story text. It cannot hang the browser or let story text turn into hidden code; the surrounding code deliberately renders text safely.
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 regex matches a closed set of short literal tag names with one optional literal attribute, contains no nested quantifiers, no alternation of variable-length groups under repetition, and no ambiguity that could cause catastrophic backtracking; input length is bounded by a single turn of prose. It is used with matchAll to find emphasis tags in model-generated prose, and the surrounding rendering code builds DOM nodes directly rather than using innerHTML, with the color attribute restricted to a class name from a closed vocabulary. This is a well-constructed, linear-time pattern and the rendering path it feeds is designed specifically to keep model output from becoming markup. At worst, a pathological input only slows matching linearly with text length, which is the recoverable, low-impact case.
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.