Skip to content

Releases

Plompy 0.13.0: Local MCP, ready-made Docker images

Choose a tag to compare

@dalkedev dalkedev released this 12 Nov 16:45
e57c6ab

Plompy Local is ready to pull from GHCR. Connect OpenCode, Codex, Claude Code or another compatible MCP client to tools running in Docker, without building from source. Your agent and model stay in your host client; Local mode does not need Discord.

Start without a source checkout

Download the attached plompy-local-0.13.0.tar.gz, extract it into a new directory, then run:

docker compose pull local
docker compose run --rm -T local node scripts/integrations.mjs init --mode local
docker compose up -d local
docker compose exec -T local node scripts/integrations.mjs test --mode local

Follow the Docker quickstart and the OpenCode, Codex or Claude Code connection guide. The kit contains Compose, security profiles, client configuration examples and a checksum manifest. Its separate .sha256 asset verifies the downloaded archive.

Images

All three variants support Linux amd64 and arm64, including Docker Desktop on Apple Silicon:

Image Use
ghcr.io/dalkedev/plompy-engine:0.13.0-local Local MCP, public page fetching and JSON/CSV artifacts
ghcr.io/dalkedev/plompy-engine:0.13.0-local-browser Local MCP plus sandboxed Chromium for rendered pages
ghcr.io/dalkedev/plompy-engine:0.13.0 Existing Discord engine with its Codex runner

Optional integrations add search, repositories, documentation and analytics. See the integration catalog. Ollama can supply the host agent's model; no model is bundled. Credentials and artifacts persist in separate private volumes. The gateway can save email drafts but does not send email.

The release workflow tests each image on both native architectures before promoting those exact OCI bytes, including provenance and an SBOM. Checks cover authenticated MCP, artifact persistence and the Chromium sandbox. Actual-client acceptance used OpenCode 1.19.5 and Codex with a deterministic local model fixture; live model-provider inference and private vendor accounts were not used as release tests.

Existing Discord installations keep SQLite schema 6 and are not updated automatically. See the changelog and upgrade guidance.

Plompy Engine 0.12.0 — small fish, your whole machine

Choose a tag to compare

@dalkedev dalkedev released this 11 Nov 22:43

Meet Plompy

The engine is now plompy-engine, with an orange fish mascot, new README artwork and a refreshed project identity. It is the same self-hosted engine: private Discord threads, provider-bound coding sessions, a durable queue and Markdown memory on your own machine.

Upgrade compatibility

  • New configuration uses PLOMPY_*; legacy SZPONT_* settings remain accepted, with explicit new settings taking precedence.
  • Existing managed MCP files, browser identity, session state and cross-version locks remain usable. SQLite stays at schema 6.
  • Existing Docker installations can reuse their exact persistent volumes and physical legacy paths using compose.legacy.yaml.
  • Python uses plompy_browser / plompy-browser, with compatibility aliases for existing installations.

Before upgrading, follow the migration guide. Stop the old worker, keep a coordinated private backup and retain the same persistent data. A repository rename does not automatically upgrade your private VPS or Discord application.

Verified build

The tagged source passed the engine, Python, MCP and Playwright checks. The release workflow built and smoke-tested native Linux amd64 and arm64 OCI artifacts before publishing those same bytes. Upgrade regressions cover legacy tool approval, strict credential paths and shared-volume identity.

Public image: ghcr.io/dalkedev/plompy-engine:0.12.0

Pinned release:

ghcr.io/dalkedev/plompy-engine@sha256:004fc8c56f23ebae0a5324b132061929c3f1d085fef47f7451704b36c9ae1a73

The attached brand kit contains the original transparent mascot, README banner, social card and usage notes.

Documentation · Buy me a coffee

Szpont Engine 0.11.1 — unattended Playwright

Choose a tag to compare

@dalkedev dalkedev released this 10 Nov 17:44
abdf7af

Unattended Codex sessions can now use the built-in Playwright MCP server with an explicit, server-scoped approval policy.

npm run integrations -- add playwright --runner codex --yes --tool-approval approve

The default registration and --yes behavior remain unchanged. Use --tool-approval prompt when you want prompts instead. The option applies only to the built-in Codex Playwright server; other integrations, runners and global approval settings retain their own policies.

This patch also preserves operator restrictions that codex mcp get omits, validates scoped configuration with the installed CLI, and writes it atomically. Existing customized entries are reported as conflicts. See the integration guide for migration from an existing managed entry.

Verification includes the engine and configurator suites, an independent real Codex 0.166.0 configuration roundtrip, and actual browser interaction with a synthetic localhost application: a new tab, navigation, snapshots, typing, a button click and screenshot, with no approval denial.

SQLite schema remains 6. Browser sandboxing and existing provider/session bindings remain unchanged. Playwright and its browser are still provisioned separately on the host; this release does not add Chromium to the core Docker image.

Docker image (verified Linux amd64 and arm64):

docker pull ghcr.io/dalkedev/szpont-engine@sha256:470ad7540f0f0b7a009bb14c71f57c5168beaf1528bfb6a8a9bc3258ab5bfd4f

Szpont Engine 0.11.0 — browser, research and analytics tools

Choose a tag to compare

@dalkedev dalkedev released this 10 Nov 16:08
bc90a22

Szpont gains browser, research and analytics tools that can be configured independently for Codex, Claude Code and OpenCode.

New integrations

  • Playwright: optional pinned Microsoft MCP server, isolated headless Chromium, private per-launch output and Chromium sandbox enabled. Includes a real localhost acceptance test for navigation, observed references, typing, clicking, screenshots and concurrent context isolation.
  • Perplexity, Firecrawl and TinyFish: official hosted MCP endpoints, native OAuth or a private API-key file. Firecrawl also offers explicit limited keyless mode.
  • PostHog: server-side read-only access to your own analytics project. This integration adds no tracking SDK or engine telemetry.

API-key mode uses a pinned provider-neutral stdio bridge. Keys stay out of managed configuration, arguments and the whole-agent environment. The bridge fixes vendor destinations, rejects redirects, bounds requests, forwards cancellation and does not replay uncertain calls. OAuth setup records configuration without starting a login or making a service request.

Installation

Start with the integration guide. Playwright requires its separate locked package, browser download and host libraries. Restricted Ubuntu hosts can generate an exact-executable AppArmor policy for administrator review; the engine never disables kernel restrictions or Chromium's sandbox.

The Docker image includes the small API bridge and Codex. It does not include a browser, model accounts or vendor access. Claude Code and OpenCode remain experimental host adapters; supervised goals remain Codex-only.

docker pull ghcr.io/dalkedev/szpont-engine:0.11.0

Published multi-platform image, including SBOM/provenance attestations:

ghcr.io/dalkedev/szpont-engine@sha256:bc52edf3e823a5e1dc5948265ba5b1142255154b561ab05382afbd7bfb53c31d

The release workflow promotes the tested OCI artifacts without rebuilding them.
Tagged release verification and publication passed for both architectures.

Upgrade and validation

Take a private backup and stop/drain active work before an upgrade. Node 26.13.0 LTS or newer 26.x and SQLite 3.54.0 remain required. Schema 6, saved sessions, provider bindings and recovery semantics are unchanged.

All six pre-release checks passed, including Linux browser acceptance and amd64/arm64 offline container tests. Additional independent reviews checked credential isolation, transport deadlines/cancellation, executable ownership and policy injection rejection. Tests use synthetic local fixtures; vendor OAuth, paid APIs and account entitlements require your own separate verification.

Full changelog · Reviewed PR

Szpont Engine 0.10.0 — Node 26 LTS

Choose a tag to compare

@dalkedev dalkedev released this 10 Nov 14:05
d09b9c8

This release requires Node 26 LTS, at least 26.13.0 and below 27, with linked SQLite 3.54.0 or newer. It replaces the affected Node 24 runtime to address CVE-2026-119375 tracked in #11. Upgrade the host runtime together with the engine; older 0.9.x images remain affected.

Runtime and state protection

  • Pin both Docker stages to the verified official Node 26.13.0 multiarch index; include libatomic1 required by official Linux binaries.
  • Compare SQLite runtime metadata with an actual fresh in-memory SQL query. Startup, Store construction, setup and snapshots reject unsupported or inconsistent runtimes before filesystem database access.
  • Add required sqlite_runtime diagnostics. A Node-major assertion alone cannot pass this security requirement.
  • Move CI, package requirements/types, .node-version, .nvmrc, installation and backup documentation to the same supported runtime contract.
  • Preserve public SQLite schema 6, provider bindings, saved sessions and explicit recovery semantics. No database migration or automatic job replay is introduced.

Verification

The exact source passed all five PR CI jobs. Linux runs 573 engine/script tests and 36 browser tests; the 55 permission/snapshot checks also run under private umask 0077. macOS passed 572 with one Linux-only skip. Regression tests verify rejection before database modification and WAL/snapshot/restore behavior.

Official macOS arm64 and Linux x64 archives were checksum-verified; actual runtime metadata and in-memory SQL queries report Node 26.13.0/SQLite 3.54.0. Both native container architectures verify their actual linked SQLite, Codex 0.166.0, sandbox and synthetic persistence.

A coordinated private host backup preceded a staged runtime rollout. Its complete 377-test suite passed. All logical tables and configuration were retained before resuming, and zero active turns were interrupted. The actual Node child process beneath the systemd wrappers was verified; temporary verification configuration was removed. No new live model or multi-day soak claim is made by this runtime upgrade.

Verified image

docker pull ghcr.io/dalkedev/szpont-engine@sha256:307e901924b44cf228f2443056aaa1bc919f4edc4e2717c45926e0306498909f

The amd64 and arm64 manifests identify revision d09b9c8448b6b36972fb01f7cc2fe1ba72d7f5e8, version 0.10.0 and Node 26.13.0, with SPDX SBOM and SLSA provenance. The release workflow promoted the exact tested OCI bytes without rebuilding; attached JSON identifies the observed manifest digests.

Upgrade

Use the quick start, runtime finding record and backup guide. Linux host installations need libatomic; the supported image includes it. Take a coordinated backup and drain active work before switching an existing service. Keep previous binaries and the matching private backup for rollback.

Codex remains the verified container runner; Claude Code and OpenCode remain experimental host adapters. This release changes runtime prerequisites, not their permission or isolation boundaries.

Szpont Engine 0.9.0 — install, inspect, verify

Choose a tag to compare

@dalkedev dalkedev released this 10 Nov 11:24
66012d4

Szpont Engine 0.9.0 makes the first private installation reproducible: guided setup, explicit Discord diagnostics, and a small code goal whose result is checked independently.

What changed

  • npm run setup: private workspace and configuration, hidden token prompt or explicit token file/stdin, all three runner choices, and refusal to overwrite existing installations. Concurrent workspaces of uncertain ownership are preserved.
  • doctor --check-discord: bounded GET-only checks for bot identity, server owner, private forum and reply permissions. No messages or model calls; default diagnostics remain offline.
  • acceptance init / verify: a supplied Git fixture, expected 22/25 RED baseline, independent 25-case verification, and rejection of weakened tests or altered evidence.
  • Native Docker acceptance now runs the actual installer and Codex CLI, checker RED/GREEN controls and the existing sandbox/persistence checks.
  • Fresh Discord guild ownership and role validation fixes false startup rejection from incomplete Gateway caches and rejects stale ownership.
  • Clearer setup, first-goal, Docker and upgrade documentation; permission-sensitive fixtures work under private umasks.

Install

Follow the quick start, setup guide, or Docker guide. The image supports Linux amd64 and arm64 and packages Codex only. Claude Code and OpenCode remain experimental host adapters.

Verified image for reproducible deployments:

docker pull ghcr.io/dalkedev/szpont-engine@sha256:a0a9067b22fc1798ce02efed828313a4f388440174a97fe1115749c8d34867ab

Both runtime architectures carry revision 66012d42dccbdad6b514150f2b20618c09163c10, SPDX SBOM and SLSA provenance. Attached JSON records identify the observed index and runtime digests. The release workflow promoted the tested OCI artifacts without rebuilding.

Verification and limits

Linux CI: 565 engine/script tests and 36 browser tests; an additional 55 permission/snapshot checks run under umask 0077. macOS: 564 PASS and one Linux-only skip. Native container gates test the real sandbox, pinned CLI, installation and synthetic persistent state without networking or credentials.

A separate Linux installation passed setup, real Discord REST diagnostics and installation smoke. Actual Discord intake and failure receipts were verified. The isolated public deployment did not complete a model session: the reused authentication profile required a private MCP context. Same-session model continuation, model-driven supervisor acceptance and multi-day soak remain unverified. No failed job was automatically replayed, and the production service was not restarted for this test. See the measured validation record.

Public SQLite schema remains 6. Preserve a coordinated backup before upgrades. Run setup on the normal service-account host or supported image; UID-remapped agent sandboxes can intentionally fail strict ancestor ownership checks.

The known Node 24 SQLite finding remains open. This release does not claim a patched embedded runtime. Full 1.0 acceptance gates remain in the roadmap.

Szpont Engine 0.8.1 — safe goal recovery under queue pressure

Choose a tag to compare

@dalkedev dalkedev released this 09 Nov 21:36
e4daa4f

!goal resume now obeys the shared 30-job queue bound. A full queue leaves the goal paused, keeping its saved worker candidate and remaining budget intact. Check !queue and retry resume after a slot becomes available; a new goal or budget is unnecessary.

This patch retains SQLite schema 6, existing provider bindings, supervision and authorization. Packages and container defaults use 0.8.1. A public release does not update a private deployment automatically.

Offline validation: 497 tests passed on macOS with one existing Linux-only filename case skipped, plus independent goal/store boundary checks. Release/container acceptance must be read from the exact tagged workflow and immutable published digest.

Verified container

ghcr.io/dalkedev/szpont-engine@sha256:e1806fa01e5a74670d5ea30055904d9980c88c37c2ccd92882941e4cbc75e653

Linux amd64 and arm64 completed the tagged offline container smoke and publication workflow. Anonymous registry reads verified both runtime manifests, configuration labels, source revision e4daa4f736a6a6b966699ff03354b739d051d727 and attestation references. Tagged workflow.

Known runtime limitation

Known runtime finding: Node 24.22.2 embeds SQLite 3.53.4, affected by CVE-2026-119375. No newer official Node 24 release was available when checked on 2026-11-09. The queue-capacity fix in 0.8.1 does not remediate this dependency finding. Use only trusted state and backup files, including sidecars; follow tracking issue #11 for verified runtime remediation.

Szpont Engine 0.8.0 — evidence for every reviewed step

Choose a tag to compare

@dalkedev dalkedev released this 09 Nov 17:25
f25eaf8

Supervised goals now carry evidence of what the worker actually changed. Bind a repository and each fresh supervisor receives a before/after patch covering implementation and tests—even when the worker committed its changes before returning.

!goal 30m --repo /var/lib/szpont/artifacts/app Fix the parser and verify regressions.
  • Capture working-tree bytes before and after each worker phase, including nonignored new files; start the next phase from a fresh baseline.
  • Save the candidate, measured execution time and sealed code evidence atomically. Pause and reviewer recovery reuse the original patch instead of reading a later live diff.
  • Give supervisors bounded change inventories, content hashes, patch excerpts, private evidence files and the two most recent review receipts. The review prompt explicitly calls out implementation changes and weakened test assertions.
  • Keep repository selection explicit and within existing workspace/artifact access. Unbound and legacy goals report unavailable evidence. Sensitive paths, binary content, unsafe traversal and capture limits are reported as omissions.
  • Preserve repository bindings and evidence through verified SQLite snapshots, with migration and recovery regression coverage.

This is observed evidence, not a guarantee of authorship or a replacement for tests. Concurrent processes can change a working copy; use isolated repositories for independent goals. See code-diff behavior and limits.

Upgrade: take a coordinated state snapshot and workspace checkpoint before upgrading. Version 0.8.0 migrates SQLite schemas 0–5 to schema 6. Older binaries cannot read schema 6; rollback requires the matching pre-upgrade state and reconciliation of later effects. Existing goals receive no implicit repository binding. See backup and restore.

Validation: 497 Node tests and 36 locked Python browser tests passed on the tagged source. Both native Linux container smoke jobs passed; the published image promotes those tested OCI bytes with provenance and SBOM attestations.

docker pull ghcr.io/dalkedev/szpont-engine:0.8.0

For reproducible deployments:

ghcr.io/dalkedev/szpont-engine@sha256:b8f43d13585fc74700f116fc6800f77dad9e2de2285aa7097cb9f4e59b7b00f1

The image supports Linux amd64 and arm64. Codex remains the default and the only packaged container runner. Host adapters for Claude Code and OpenCode retain their existing experimental status.

Szpont Engine 0.7.0 — supervised goals

Choose a tag to compare

@dalkedev dalkedev released this 07 Nov 21:29
4ac605c

Run a fixed Codex task through independently reviewed steps with !goal and its !loop alias. The worker keeps its session; each supervisor starts fresh.

!goal 2h Implement the agreed feature, verify regressions and prepare a PR.
!goal status
!goal pause
!goal resume
!goal stop
  • Share one active execution budget across worker and supervisor: 30 minutes by default, 1–120 minutes explicitly, up to 32 reviewed steps.
  • Save worker candidates before review. Preserve supervision, session and spent time through explicit recovery; avoid replaying a worker just because its reviewer failed.
  • Stop on missing input, uncertain execution or three stalled reviews. Renew a supervised budget with !goal; an ordinary !work explicitly opts out of supervision.
  • Fix phase-budget accounting when persistence fails, including errors after a successful commit.

Upgrade: public SQLite schemas 0–4 migrate to schema 5. Take a coordinated state/workspace snapshot and retain the matching binary. Version 0.6.1 cannot open schema 5; rollback requires restoring compatible pre-upgrade state and reconciling later actions.

Supervised goals currently require Codex. Claude Code and OpenCode remain experimental host adapters for ordinary tasks. Supervisors have a read-only filesystem sandbox; configured MCP permissions remain an operator responsibility.

Validation: 460 offline tests, browser suite, native amd64/arm64 container smoke checks and actual configured CLI/private Engine-port acceptance with resumed workers, fresh supervisors and completed native subagents. The validation record distinguishes synthetic fixtures, actual CLI integration and installation-specific checks.

Container

docker pull ghcr.io/dalkedev/szpont-engine:0.7.0

Immutable multi-platform image:

ghcr.io/dalkedev/szpont-engine@sha256:1433d055a9e3b5a9de3e76dab71d879fef520eba0f4ab6ba975a8e39436e6951

Published for Linux amd64 and arm64, with provenance and SBOM attestations. Release CI tests the exact OCI archives before promoting their unchanged bytes; anonymous registry reads verified both platforms, labels and digest. This release does not automatically upgrade private deployments or provide model credentials.

Szpont Engine 0.6.1

Choose a tag to compare

@dalkedev dalkedev released this 06 Nov 19:40
afdb960

Know why work is waiting

!queue lists this thread's queued and running task IDs in accepted order, explains the waiting reason and points to the blocking task's saved result when recovery is needed. It uses scheduler predicates without calling a model, retrying work or exposing other conversations.

Status, default !result readback and recovery suggestions now follow durable acceptance order, so a host clock correction cannot select an older workflow or failure.

This patch retains public SQLite schema 4, existing runner bindings and the single-worker execution contract. The container remains Codex-only; Claude Code and OpenCode remain experimental host adapters. Updating public source or pulling the image does not upgrade an existing private deployment automatically.

Back up coordinated private state and workspace before upgrading, then reconcile uncertain actions before recovery or rollback. See the upgrade guide.

Verified container image

Linux amd64 and arm64, with SBOM and build provenance:

ghcr.io/dalkedev/szpont-engine@sha256:75128f64620441d3aba1a036593ccdd4e34010d945c818a661d0432c1b783dcd

The published manifest set matches the exact OCI archives tested by the release workflow, from source commit afdb960. Pin the digest for repeatable deployments.