Ódinn Forge Is Now in Public Beta

Ódinn Forge is now available as a public beta.

I built it for people who want an AI agent that can do real work without quietly turning their machine into an unattended blast radius. It is local-first, cross-platform, provider-flexible, and designed so dangerous choices are visible instead of buried behind a confident chat response.

The source, release artifacts, installation guide, and issue tracker are public:

github.com/jason-allen-oneal/Odinn

Why Another Agent Runtime?

Most agent systems eventually collide with the same problem. Generating text is easy. Letting a model read files, browse the web, operate accounts, remember context, run tools, and recover after failure is where the machinery gets sharp.

Ódinn Forge treats that boundary as the product.

The runtime combines a policy-aware kernel, durable memory, model and provider adapters, browser and web capabilities, sessions, audit trails, scheduled jobs, and a local chat console. Actions that can change external state require explicit approval. Tool execution crosses one audited path. Recovery state survives restarts instead of disappearing into a log file nobody reads.

It is a clean-room implementation with its own contracts, storage, and security model.

What Works in the Public Beta

The supported beta path is one operator running the loopback-only gateway on a machine they control.

Current users can:

• connect cloud APIs, OAuth-backed providers, local model servers, or CLI adapters;
• keep durable user and project context across sessions;
• search and read the public web;
• use an isolated browser profile for accounts they sign into manually;
• require approval before browser actions that change external state;
• inspect sessions, memory, runs, goals, providers, usage, scheduled jobs, and audit events;
• run deterministic tools and bounded model/tool loops through the audited kernel;
• register and inspect declarative Agent SDK packages and reviewed skills without silently executing them.

Experimental Proof, Rewind, Sentinel, Capsules, Darwin, Capability Tokens, Counterfactual execution, and self-improvement features are present but disabled by default. Each one must be enabled deliberately. They are research surfaces, not magic words that make remote systems reversible.

Security Boundaries That Say What They Mean

The beta was delayed until the documented boundaries matched the runtime.

Browser traffic validates destinations before navigation and intercepts requests so public-looking hostnames cannot quietly pivot into loopback, private, link-local, or metadata networks. Web fetching pins validated DNS answers and stops oversized responses instead of draining an endless stream.

Extension execution defaults to a container boundary with bundle integrity checks. The unsafe process mode is named as unsafe and requires an explicit operator choice. Proof contracts cannot select arbitrary executables without an exact operator-controlled allowlist. State restore rejects symlinks and special files before copying them into trusted state.

The single-user gateway stays on loopback. The optional multi-user host uses TLS and tenant-specific state, workspaces, audit ledgers, OAuth stores, and browser profiles, but it is documented honestly as application-level separation rather than hostile-code containment.

That distinction matters. Security controls should reduce authority, not just rename it.

Release Evidence

The current public beta release is v0.3.0-beta.1.

Before publication, the release passed 112 tests with zero failures. CI, security scanning, dependency auditing, workflow linting, package integrity, integration tests, packaged inference, and platform checks completed across Linux, macOS, and Windows.

The release workflow also built and verified:

• ZIP and tar.gz archives;
• a SHA-256 checksum file;
• an SPDX software bill of materials;
• a release manifest;
• build provenance attestations;
• an installation smoke test against the packaged artifacts.

The protected release workflow verified the candidate, ran the packaged installation smoke, produced checksummed archives and an SBOM, and uploaded build-provenance attestations. The release tag, local main branch, and remote main branch resolve to commit ba4f5ebab49d424b819cb689f6006b2a50b6cc7c.

That does not mean the beta is bug-free. It means the starting artifact is identifiable, reproducible, and inspectable. There is a difference.

Who Should Test It

This beta is for developers, security practitioners, local-AI users, and operators who are comfortable running Node.js tooling and reporting rough edges with useful evidence.

Good beta feedback includes the operating system, Node.js version, provider, exact command or UI action, expected result, observed result, and sanitized logs. Remove credentials, OAuth tokens, cookies, private prompts, and identifying filesystem paths before opening an issue.

Do not use the beta as a safety-critical service or a hostile-code sandbox. Do not expose the single-user gateway to a network. Review imported skills, MCP servers, extensions, and browser pages as untrusted input.

Try It, Break It, Report What Bleeds

The repository contains the verified-release installation steps, public beta guide, architecture notes, security policy, feature documentation, and issue templates.

Start here:

github.com/jason-allen-oneal/Odinn

If onboarding is confusing, a provider behaves differently than documented, a restart loses state, an approval boundary leaks, or the interface hides something an operator needs to see, file a precise report.

The point of a public beta is not applause. It is signal.