Hi maintainers — this is not a security report, just a friendly architecture-quality audit note from hermescheck, a repo scanner for AI agent/runtime systems.
I ran a narrow runtime-oriented pass against gitagent, and three implementation-level themes looked worth sharing:
- Plugin loading may be fragile on Windows. In
src/plugins.ts, the programmatic plugin path is built with join(pluginDir, manifest.entry) and passed directly into import(...). On POSIX this often works, but on Windows ESM loading usually wants pathToFileURL(entryPath).href, otherwise absolute filesystem paths can fail or behave inconsistently.
- One-shot schedules appear to rely on a raw
setTimeout(delay) path in src/schedule-runner.ts. For far-future runAt timestamps, Node timer limits can overflow or clamp long delays, which can make "run once later" jobs fire incorrectly. Routing large delays through a clamp/chunk helper would make the once-scheduler more durable.
- Continuation looks strong on memory + summary + recent transcript replay in
src/context.ts, but I could not find a shared resume contract that also rechecks durable workspace/runtime side effects before continuing. After an interrupted run or reconnect, that can make the agent remember the conversation while still missing whether the underlying work actually landed.
This may be noisy or already planned, so please feel free to close if it is not useful. If helpful, I can rerun with an even tighter runtime-only scope and share a smaller evidence slice.
Hi maintainers — this is not a security report, just a friendly architecture-quality audit note from hermescheck, a repo scanner for AI agent/runtime systems.
I ran a narrow runtime-oriented pass against
gitagent, and three implementation-level themes looked worth sharing:src/plugins.ts, the programmatic plugin path is built withjoin(pluginDir, manifest.entry)and passed directly intoimport(...). On POSIX this often works, but on Windows ESM loading usually wantspathToFileURL(entryPath).href, otherwise absolute filesystem paths can fail or behave inconsistently.setTimeout(delay)path insrc/schedule-runner.ts. For far-futurerunAttimestamps, Node timer limits can overflow or clamp long delays, which can make "run once later" jobs fire incorrectly. Routing large delays through a clamp/chunk helper would make the once-scheduler more durable.src/context.ts, but I could not find a shared resume contract that also rechecks durable workspace/runtime side effects before continuing. After an interrupted run or reconnect, that can make the agent remember the conversation while still missing whether the underlying work actually landed.This may be noisy or already planned, so please feel free to close if it is not useful. If helpful, I can rerun with an even tighter runtime-only scope and share a smaller evidence slice.