tsouth89/toolport

Problem Code mode (toolport_run_script) runs an untrusted script in an embedded JS interpreter. Limits (src-tauri/src/codemode.rs:113-124) bounds everything except allocation: Limits { max_calls: 64, wall_clock: Duration::from_secs(60), max_parallel: 8, max_promise_jobs: 100_000, loop_iteration_limit: 10_000_000, recursion_limit: 400, } Those bound time and iteration count, not bytes. A script can allocate arbitrarily in very few iterations: let a = [1]; for (let i = 0; i < 30; i++) a = a.concat(a); // ~1G elements, 30 iterations That is far under loop_iteration_limit, never yields to the promise-job executor, and never reaches a host-call reserve, so no existing limit fires. The wall clock is only checked at host-call reserve and between jobs (codemode.rs:962-971, :160), so it never gets a chance either. Rust OOM is an abort, not a catchable error, so the process dies. There is also no size cap on the submitted script. src-tauri/src/bin/toolport-gateway.rs:60

Problem The Test button is disabled while test.status === "testing". But every keystroke calls clearTest(), which resets any non-idle status back to "idle" — including "testing". It does not distinguish "a stale result exists" from "a test is in flight", and nothing cancels or tags the pending testServer call. So editing a field during a test re-enables the Test button while the first request is still outstanding, and there is no request-generation guard to discard a late response. Where: src/components/ServerDialog.tsx:101-103 (clearTest) src/components/ServerDialog.tsx:501 (the disabled gate) Callers: set() and setEnvRow() Failure scenario A user clicks Test on a working config. While it is in flight they edit the command to something broken, which flips the status back to idle and re-enables the button. They click Test again. The first call, made against the working config, resolves after the second and writes { status: "ok", message: "Connected. Found N tools." }. The dialog no

Problem handleSave calls addServer/updateServer first, then loops over declared secrets calling setSecret for each. If a setSecret throws after the server was already created, control lands in the single catch, which shows Couldn't save <name> and nothing else. onSaved(result) is never called, so the parent's registry state never learns the server exists, and the dialog stays open with entry.id still "". Where: src/components/ServerDialog.tsx:260-278 Failure scenario A user adds a server with two env secrets. The server is created, the first setSecret succeeds, the second throws because the keychain is locked. The user sees "Couldn't save X" and believes nothing happened. In fact the server exists and one secret is vaulted. They click Save again; because this is not edit mode, addServer runs a second time and creates a duplicate server entry. Acceptance criteria A failure after the server was created is reported as a partial success, naming what did and did not happen. The parent is

Problem bump_secrets_generation discards the result of write_registry. Per its own doc comment, that write is the sole mechanism that makes a running gateway reload after a keychain-only change. All three callers return Ok immediately afterwards, so a failed bump is invisible to the caller and to the user. Where: src-tauri/src/desktop.rs:2961-2966 (bump_secrets_generation) Callers: set_auth_token, clear_auth_token, authenticate_oauth Failure scenario A user clicks "Clear token" to revoke a leaked bearer. The keychain delete succeeds. registry::update then fails, because the cross-process registry lock is held by a running gateway or the disk is full. The command returns Ok, the UI shows the token as removed, and the already-running gateway never reloads. It keeps serving requests with the credential the user believes they just revoked. The same path makes a fresh OAuth sign-in silently not take effect, leaving the user looking at 401s from a server they just authenticated against. Ac

Problem stop_http_bridge takes the child out of the tracked state, discards the result of both kill() and wait(), clears the port and token, and returns a status whose running field is derived from port.is_some() — so always false. The same file already knows how to do this. stop_spawned_gateways inspects the kill() result, falls back to try_wait, and puts the child handle back on failure. stop_http_bridge itself is careful about the resume marker directly above, with a comment about not silently resurrecting something the user disabled, and then drops that care for the actual kill. Where: src-tauri/src/desktop.rs:4225-4231 (stop_http_bridge) Correct pattern: stop_spawned_gateways in the same file Failure scenario The user turns off the HTTP endpoint in Settings. kill() fails (access denied on the handle on Windows, or the child is mid-syscall). The UI reports the endpoint stopped, but the gateway keeps listening on 127.0.0.1 and keeps honoring every bearer token already issued to