sympozium-ai/sympozium

Summary The chart deploys a postgres MCPServer (crystaldba/postgres-mcp) with no DATABASE_URI, so it crashloops from the first minute after a clean install. Worse, it reports READY: true while doing so. Environment sympozium v0.10.51, chart sympozium-0.10.51 Fresh install on a cleaned cluster Actual behaviour Two minutes after sympozium install: $ kubectl logs -n sympozium-system deploy/postgres --tail=5 ValueError: Error: No database URL provided. Please specify via 'DATABASE_URI' environment variable or command-line argument. stdio process exited: exit status 1, restarting with backoff The Deployment's env block contains only stdio-adapter variables (MCP_STDIO_ADAPTER, STDIO_CMD, STDIO_ARGS, STDIO_SERVER_NAME, STDIO_PORT) — no DATABASE_URI, no envFrom, and no matching Secret in the namespace. On a previous 9-day-old install this pod had accumulated 55 restarts. Secondary issue: READY is misleading NAME TRANSPORT READY SUSPENDED TOOLS postgres stdio true The li

Summary sympozium install segfaults during the Helm phase when ~/.kube/config exists but contains no clusters, even though KUBECONFIG is set to a valid kubeconfig elsewhere. The CLI appears to ignore KUBECONFIG entirely. Environment sympozium v0.10.51 (Homebrew) macOS, arm64 Kubernetes: external cluster, cert-manager v1.17.1 installed and healthy Steps to reproduce export KUBECONFIG=/path/outside/dot-kube/cluster.yaml Ensure ~/.kube/config exists but has no clusters/contexts (109-byte stub) Verify kubectl works: kubectl config current-context → returns the context Run sympozium install Actual behaviour CRDs and Gateway API CRDs apply successfully, cert-manager check passes, then the process panics: Running Helm install... panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x2 addr=0x58 pc=0x1043fd214] helm.sh/helm/v3/pkg/kube.(*Client).IsReachable(0xa?) helm.sh/helm/[email protected]/pkg/kube/client.go:136 +0xc4 helm.sh/h

Context PR #347 introduces a valuable seam: an external harness adapter can replace agent-runner while retaining the surrounding Sympozium pod and result lifecycle. Thank you @kristof-ringleff for pushing this direction forward and for providing the DSH proof of concept. We want to preserve the lightweight, externally maintained adapter model and keep you involved in defining the adapter contract and reference examples once the security foundation below is in place. A security, ecosystem, and product review found that the current implementation should remain experimental until the runtime trust boundary and operator experience are explicit. Goal Ship BYO harness support as a versioned, policy-controlled runtime capability that is safe to operate, visible in the UI, usable through normal Sympozium entrypoints, and backed by runnable examples and conformance tests. P0: security boundary Add an explicit harness/runtime policy opt-in that defaults to disabled. Separate run submission fr

Summary When spec.memory.enabled: true on an Agent, the controller injects an AgentRun Job init container wait-for-memory with a hardcoded image busybox:1.36 (Docker Hub short name). In clusters that cannot pull from Docker Hub (air-gapped / corporate registry mirrors that return HTML for short names), the init never starts (ErrImagePull / ImagePullBackOff). The long-lived *-memory Deployment can still be Ready and healthy — the failure is only the wait init on the AgentRun pod. Agent-runner, ipc-bridge, and skill sidecars never start. There is no Helm value or env (unlike SYMPOZIUM_IMAGE_REGISTRY / SYMPOZIUM_IMAGE_TAG for Sympozium images) to override this busybox image. Environment Sympozium chart / CLI: v0.10.48 Kubernetes: private cluster with registry pull-through / Artifactory; Docker Hub short names fail Memory: Agent.spec.memory.enabled: true (legacy memory server Deployment path) image.registry / SYMPOZIUM_IMAGE_REGISTRY correctly rewrites agent-runner, ipc-bridge, memory-s

RFC: Scion Runtime Backend for Long-Lived Interactive Agent Sessions Background Sympozium's ephemeral-Job model is excellent for event-driven, short-lived agent runs (channel messages, scheduled heartbeats, API requests). However, it creates friction for long-lived, interactive coding sessions — the kind where a human needs to attach mid-run, inspect progress, and send follow-up instructions. This is exactly the gap GoogleCloudPlatform/scion is designed for. Scion is a multi-agent orchestration testbed from GCP that manages long-lived agent processes in containers with: tmux-based interactive sessions (attach/detach, message enqueue) Git worktree isolation per agent (clean branch per agent, no merge conflicts) Support for Claude Code, Gemini CLI, Codex, OpenCode as harnesses A Runtime Broker model — compute nodes register to provide execution capacity OTEL telemetry (same stack as Sympozium) Proposed Integration Pattern Sympozium becomes the channel layer, memory layer, and polic