Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

(bug) The runner is OOMKilled with three local sessions at a 1Gi limit, and the chart and docs give no sizing guidance

Open Beginner friendly
  • Is something wrong?
#7,441 1 comment 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
83/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
docker-compose, helm, kubernetes
Domain
devops, documentation

Research direction

Read hosting/kubernetes/helm/values.yaml and the “Container resources” section in docs/docs/self-host/agents/04-customize-the-agent-runtime.mdx; check the Compose override there too. Document the reported idle and per-session memory guidance, and add a commented chart example for a few local sessions. Done when both deployment paths explain sizing and the chart example reflects the guidance.

Written by the indexing model from the issue text.

Description

bug

The agent runner container is killed for lack of memory when several local-sandbox sessions run in the same pod with a 1 GiB memory limit. The Helm chart and the docs give no sizing guidance for this case, so a self-host that picks 1 GiB hits it.

Reproduce

  1. Deploy the chart with the local sandbox provider and set agentRunner.resources.limits.memory: 1Gi (request 512Mi).
  2. Open three agent conversations (Pi harness) at about the same time and send a message in each.
  3. Watch the runner pod with kubectl top pod and kubectl describe pod.

Expected

The runner holds three concurrent local sessions without being killed, or the chart and the docs say how much memory each local session needs.

What we saw (GKE oss, local sandbox, v0.122.4 release candidate)

  • Idle runner after a restart: 178 to 313 MiB.
  • One session at a time (approve cell, deny cell, client-tool cell): peak 465 MiB.
  • Two sessions together (a gate cell plus one browser session): peak 890 MiB of 1 GiB.
  • Three sessions: the container was OOMKilled (exit 137, restart count 1). Turns that were running ended with "peer closed connection" or "All connection attempts failed". One browser turn stayed on "Thinking" for about 100 seconds until the api watchdog settled it.

The local sandboxes (one Pi daemon per session) run inside the runner container, so memory grows with each concurrent session. The limit is the same on v0.122.3, so this is not a regression of the release.

Where to change

  • hosting/kubernetes/helm/values.yaml: the chart sets no default for agentRunner.resources. The template hosting/kubernetes/helm/templates/runner-deployment.yaml renders only what the user sets, so the 1 GiB limit in our run came from the deployment values, not from a chart default. Add a commented example with a limit that fits a few local sessions (for example request 1Gi, limit 2Gi or more).
  • docs/docs/self-host/agents/04-customize-the-agent-runtime.mdx ("Container resources"): it shows 4Gi but does not say how memory grows with concurrent local sessions. Add the numbers above as guidance: about 200 to 300 MiB idle, plus a few hundred MiB for each active session.
  • The same guidance applies to the Compose override in that page.

Notes

This is not a code defect in the runner. The ask is a documented example (and optionally a chart default) that survives three concurrent local sessions.

🤖 The AI agent says: filed from the v0.122.4 release QA.

Dominant language
TypeScript
Stars
4.8k
Forks
690
Avg merge
19h 47m
Merged PRs (30d)
431

Getting set up

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.

More from Agenta-AI/agenta

All issues in Agenta-AI/agenta

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.