The code takes a piece of the project's own source file and runs it in an isolated sandbox to test that it works correctly. It does not run any code from outside the project or from user input.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: A new Function constructor is used to execute a source-code slice extracted from the project's own index.js file via fs.readFileSync and String.slice. The extracted slice contains the migrateTrackerWidgetSettings function, which is then invoked against test fixtures to verify widget layout migration logic. No external, user-supplied, or network-derived input reaches the Function constructor; the executed code is the project's own committed source. This is a self-contained unit-testing pattern for isolating pure functions from module side effects.
The code extracts a formatting function from the project's own source file and runs it in isolation to test its output. Nothing from outside the project is executed.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: A new Function constructor wraps a source slice extracted from the project's own index.js, specifically the formatTrackerItemDisplayName function. A trivial cleanTrackerDeltaText callback is injected as a parameter. The resulting function is called immediately to verify formatting behavior. No external or user-controlled data influences the Function body; only project-committed source code is executed.
The code pulls layout-calculation functions from the project's own source file and tests them with mock screen dimensions. Only the project's own code is executed, with no outside input.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: A new Function constructor is used to create an isolated execution context for tracker widget layout math functions (clampTrackerWidgetHeight, clampTrackerWidgetWidth, clampTrackerWidgetPosition) extracted from the project's own index.js via String.slice. A mock globalThis object with innerWidth and innerHeight is passed in. The returned functions are called with numeric test values and results are compared with assert.deepEqual. No external or untrusted input reaches the Function constructor.
This is part of the project's automated tests. It takes a piece of the project's own code and runs it in a controlled, fake environment to check that settings migration works correctly. No outside or user-controlled input is involved, and nothing sensitive is accessed.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The candidate is a `new Function` call inside a test file. It extracts a slice of the project's own `index.js` source (the `getSettings` function body) and executes it with fully controlled mock arguments: a fixed retired-settings store, constant string keys, empty objects, and arrow-function stubs. No untrusted or external data flows into the constructor or its arguments. The pattern is used to unit-test an internal function that is not exported, with no network access, credential access, persistence, or side effects beyond an in-test counter. This is a legitimate test-harness technique.
This is another automated test. It runs a piece of the project's own code in a controlled, fake environment to verify that thinking-format settings behave correctly per connection profile. No outside or user-controlled input is involved, and nothing sensitive is accessed.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.javascript-eval in this repository.
Contextual assessment: The candidate is a second `new Function` call in the same test file. It slices a portion of the project's own `index.js` source (thinking-disable format helpers) and executes it with controlled mock arguments: imported constants and arrow-function stubs that return fixed profile and route objects. No untrusted or external data is passed in. The dynamic execution is confined to the test harness and is used to verify per-profile thinking-disable resolution logic without exporting the internal helpers. There is no network, credential, or persistence interaction.
All three new Function candidates share the same self-contained test pattern
low risk · high confidence
All three flagged code blocks use the same testing approach: they copy specific functions from the project's own source file and run them in isolation to check that they produce correct results. Nothing from outside the project is ever executed.
Technical assessment
All three dynamic-execution candidates follow an identical pattern: read index.js with fs.readFileSync, extract a function body via String.slice using known function-name boundaries, wrap it in new Function with project-defined constants, and invoke it against hardcoded test fixtures. The executed code originates exclusively from the project's own committed source. No network data, user input, configuration values, or runtime arguments influence the Function body. This is a unit-testing technique for isolating pure functions without importing the full extension module and its side effects.
Test file uses new Function to exercise non-exported internal helpers with mock data
low risk · high confidence
The flagged code lives in the project's tests, not in the extension that users run. It deliberately runs pieces of the project's own code in a fake environment to check correctness. No real user data or external input is involved, so there is no security risk to users.
Technical assessment
Both candidates occur in a file whose path and contents indicate an automated test suite. The `new Function` calls extract source slices from the project's own production files and execute them with hardcoded mock dependencies to test behavior of internal functions that are not exported. All inputs are controlled by the test, and no untrusted, network, credential, or persistent-state data flows into the dynamic execution. This is a recognized testing pattern and does not introduce a runtime security risk in the extension itself.