shareAI-lab / shareAI-lab/kode-agent-sdk

Architecture-quality audit notes from hermescheck

Open
#55 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
400
Forks
74
PR merge metrics
No merged PRs in 30d

Description

Hi maintainers — this is a friendly architecture-quality audit note, not a security report.

I've been building hermescheck, a small open-source scanner for AI agent runtimes. I ran a narrowed external pass on shareAI-lab/kode-agent-sdk because it has a compact long-running agent core with persistence, sandbox, scheduling, and provider-adapter surfaces.

Three runtime/architecture notes looked worth sharing:

  1. Recovery looks partially state-aware, but not yet like one explicit resumability contract.
    src/infra/providers/openai.ts supports stored-state continuation through previous_response_id, and src/infra/providers/types.ts documents provider-specific history/reasoning transport constraints. That is useful groundwork, but I couldn't see one obvious higher-level contract that says what gets replayed after interruption besides model-side state, what side effects are considered durable, and how a long-running task safely resumes after a crash or restart.

  2. Startup and execution entry surfaces feel a bit spread out.
    There is quickstart.sh, direct shell execution through src/tools/bash_run/index.ts, and sandbox command execution under src/infra/sandbox.ts / src/infra/opensandbox/opensandbox-sandbox.ts. None of that is inherently wrong, but from an operator/runtime perspective it makes it harder to reason about which command path is the canonical one for bootstrap, task execution, and recovery behavior.

  3. Scheduler delays may benefit from an explicit cap or chunking rule.
    In src/core/time-bridge.ts, cron() computes a raw setTimeout delay from the next due timestamp. If this runtime is ever used for very long waits, it may be worth documenting or enforcing a max timer span and rescheduling in chunks, so large delays do not depend on one long host timer.

None of this is meant as "you must change this". It just felt like a potentially useful external architecture snapshot focused on long-running runtime behavior.

Repo for the tool: https://github.com/huangrichao2020/hermescheck

If this isn't useful, feel free to close and I won't take it personally.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read src/infra/providers/openai.ts and src/infra/providers/types.ts first, then compare the command paths in quickstart.sh, src/tools/bash_run/index.ts, src/infra/sandbox.ts, and src/infra/opensandbox/opensandbox-sandbox.ts. Inspect src/core/time-bridge.ts for the scheduler delay calculation. The issue provides an architecture snapshot but no selected change or acceptance criteria, so a contributor would need maintainers to scope what done means.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
ai-infra-agents, backend
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.