State of the Claw — Peter Steinberger

Peter Steinberger describes OpenClaw as a five-month-old project growing at a pace that strains conventional open-source maintenance. His reported figures include approximately 30,000 commits, nearly 2,000 contributors, and close to 30,000 pull requests. The central implication is that popularity does not automatically translate into sustainable ownership: a project can accumulate enormous activity while still depending too heavily on a small number of people to make consequential decisions and land changes. 0:52

The organizational answer is the OpenClaw Foundation, which Steinberger portrays as a neutral structure rather than an extension of any single company. He says the project needs to remain open and compatible with different models, including local models, while drawing support from contributors across companies. His deliberate distribution of maintainers and collaborators is intended to improve the concentration of commit responsibility without creating the impression that OpenAI controls the project. 2:33

This arrangement introduces its own management constraints. Foundation leadership resembles operating a company without equivalent authority over volunteers, and Steinberger says the project ultimately needs full-time staff to maintain development speed, improve quality, and free maintainers to build. At the time described in the talk, establishing the foundation was nearly complete but still faced banking-related administrative delays. 2:33

Steinberger reports receiving 1,142 security advisories, averaging approximately 16.6 daily, including 99 marked critical; he says roughly 469 had been published and 60% closed. This volume reflects both genuine exposure and an ecosystem in which increasingly capable AI tools can generate vulnerability reports faster than maintainers can evaluate them. His example of testing NVIDIA’s Nemo Claw with Codex Security illustrates the broader point: a nominal security boundary may contain multiple escape routes that capable automated analysis can uncover quickly. 3:42

His criticism of CVSS severity is not that vulnerabilities should be ignored, but that numerical classifications can obscure whether an exploit matches deployed reality. He discusses a maximum-severity permission-escalation scenario involving a reduced-permission device model, then argues that most users either have gateway access or do not, and that the narrower configuration is not meaningfully used. A separate remote-execution scare depended on exposing a gateway token in ways that, according to Steinberger, conflict with the local-only or private-network setup recommended by default. 6:27

Other threats remain consequential even when they originate outside OpenClaw itself. Steinberger describes deceptive distribution through a similarly named package or misleading website, and a supply-chain dependency incident in which the project was affected through MS Teams or Slack despite not directly using Axios. The engineering distinction is between an alarming label, an exploitable configuration, a compromised dependency, and a malicious distribution channel: each demands a different response rather than a uniform interpretation of reported severity. 8:10

The operational bottleneck is trustworthy triage. Steinberger says many reports appear agent-generated, but maintainers still must inspect them carefully because automated systems cannot yet be trusted to settle every case. Reports rarely arrive with useful fixes, rushed remediation can break the product, and volunteers alone struggle to absorb the workload; he credits company-supported engineers, particularly from NVIDIA, with helping review reports and harden the codebase. 9:19

Steinberger identifies a structural risk common to powerful agents: combining access to private data, exposure to untrusted content, and the ability to communicate externally. The same capabilities that make an agent valuable can create a path for information exfiltration or unwanted actions. His argument is that this tradeoff is inherent to agentic systems, not unique to OpenClaw, and that users need to understand what authority their agents actually possess. 10:50

The recommended operating model follows directly from those boundaries. A personal agent should accept instructions only from its owner; an agent placed in a group chat should be sandboxed; and a team agent should know only information that the team is authorized to access. Steinberger disputes demonstrations that ignore these recommendations or deliberately expand privileges, arguing that security evaluations should disclose the configuration and access assumptions required to produce the observed behavior. 10:50

On prompt injection, Steinberger says stronger models have improved at handling isolated untrusted material from websites or email when that content is explicitly identified as untrusted. He also acknowledges that repeated, unrestricted interaction with an agent can still create opportunities for attack. Smaller models without meaningful defensive training present a separate concern when combined with browsing or email, which is why OpenClaw warns users about small-model configurations even while continuing to support different model choices. 35:55

The discussion also raises a trust-and-reputation approach in which privileges increase as trust is established over time, while suggesting that multiple-model defenses may be worth exploring. Neither idea is presented as a completed solution. The practical limitation remains that model capability, access controls, exposure to untrusted inputs, and user configuration all interact, so no single safeguard resolves every form of agent risk. 35:55

A major motivation behind OpenClaw is data control. Steinberger contrasts a personal agent that keeps its user’s information under local control with hosted services that receive broad access through connectors such as Gmail. His preferred arrangement allows limited information to reach a higher-capability model when necessary, while preserving the possibility of local or alternative models and avoiding unnecessary dependence on a single provider. 19:40

He also argues that a user-operated agent can interact with services available to that user even when formal integrations are difficult for startups to obtain. This creates room for more flexible automation, but the transcript does not establish that such access is universally available, compliant with every service’s rules, or free of security tradeoffs. What Steinberger does establish is his preference for software that operates from the user’s existing access rather than requiring every useful workflow to depend on an enterprise connector. 23:03

The longer-term product vision is ubiquitous, context-aware interaction rather than a chatbot confined to a phone. Steinberger describes speaking to an agent from any room, allowing it to identify a nearby display and use the Canvas feature when a visual response would help, and eventually interacting through devices such as glasses. He further imagines separate personal and workplace agents communicating under arrangements acceptable to both the individual and the employer, leaving the concrete trust and authorization mechanisms as future work. 33:27

Personalization matters because an agent participates in social environments rather than merely returning search results. Steinberger says an early WhatsApp integration felt wrong because its responses were too verbose and stylistically unlike messages from friends. That mismatch led him to iterate on personality and writing style, illustrating that the appropriate behavior of an agent depends on the communication channel and the expectations of the person using it. 29:00

Steinberger describes running as many as roughly ten coding-agent sessions when model responses were slower, later reducing that to approximately five or six as execution improved. He frames this parallel-agent workflow as a response to waiting time rather than an ideal permanent way to build software: faster model output should reduce the need to keep many independent loops active simultaneously. Productivity here comes from shortening feedback cycles, not simply maximizing the number of agents. 24:03

He rejects the strongest version of a dark factory approach when it assumes that a complete product can be specified upfront and then built without continued human involvement. His preferred process is iterative: build part of the system, use it, notice what feels wrong, and revise the next prompt accordingly. Automated pipelines can help with bounded tasks, but automatically accepting contributions risks pulling a product in conflicting directions because an agent does not reliably understand which changes serve the project’s broader vision. 26:32

For Steinberger, taste begins with recognizing generic, impersonal, or obviously machine-produced writing and interface patterns, then extends to small product details that create a more distinctive experience. He connects that judgment to playful behavior in OpenClaw and to the careful adaptation of agent personality for messaging contexts. As more implementation work becomes automatable, the human contribution shifts toward identifying subtle quality differences and deciding which details are worth preserving. 27:48

The architectural counterpart is a move from a sprawling codebase toward extensions and plugins. Steinberger says memory, a wiki, Dreaming, and other capabilities can be installed or replaced independently rather than forcing every experiment into the overloaded core contribution process. He describes Dreaming as an early attempt to reconcile session logs and memories, while emphasizing that system design, asking the right questions, and declining unnecessary features remain essential because individually plausible changes can combine into an incoherent, difficult-to-maintain system. 37:58

The above paragraph also cites the full architecture and maintainability context. 39:56

Generated transcript labels and wording have not received a full line-by-line editorial review, so technical claims should be interpreted in the context of the supplied discussion and its stated limitations. 3:42