phpClaw packages an AI agent runtime for PHP, with a built-in tool-calling loop, swappable memory, seven model providers and adapters for eight frameworks and content management systems. Its GitHub README lists eight security guards enabled by default, alongside separate controls for shell commands, HTTP requests and file access.
The author introduced the project on Show HN. Daily Launch’s timeline dates that post to October 29, 2026, and lists October 30 as its first ranking date. The opened Hacker News page displays only a relative age.
For PHP teams, the useful distinction is between calling a model and operating an agent. An API client can send a prompt and receive text. An agent runtime also has to manage tool requests, return results to the model, repeat that process and decide when to stop. phpClaw assembles those pieces inside the PHP application stack.
Its most consequential design choice is the boundary it draws: tools, memory and execution controls are included; a retrieval-augmented generation system is not.
What phpClaw Runs Inside Your Application
phpClaw implements a ReAct loop: reason, act, observe and repeat. The model selects a registered tool, the runtime executes it, and the result becomes input for the next step. According to the project documentation, the loop continues until the agent produces an answer or reaches its iteration cap, which defaults to 20.
The supplied tools cover operations including shell commands, HTTP requests, file access, database queries and code search. The README illustrates tasks such as checking disk usage, inspecting an error log, counting orders with a read-only database query and finding references to a service in a codebase.
Those examples explain why the runtime matters. A question about today’s orders requires an application data source and permission to query it. The language model alone cannot supply that access.
The documented minimal setup starts with Composer and a provider credential:
composer require phpclaw/phpclaw
export ANTHROPIC_API_KEY="your-api-key"
Within a PHP application that loads Composer’s autoloader, the README’s builder and response interface support a short interaction:
$agent = \PhpClaw\Claw::builder()->build();
$response = $agent->send('Hello');
echo $response->text;
The shell commands install the package and set a credential in that shell environment. The PHP example builds an agent, sends a message and prints its text response. It does not register application tools or demonstrate a production deployment.
The author specifies PHP 8.1 or later in the Show HN introduction. The README describes a framework-independent core and lists the ext-curl, ext-json and ext-mbstring extensions.
Memory, Skills and Longer Workflows
phpClaw also documents pluggable memory and skills that the model loads on demand through a load_skill tool. A memory abstraction allows teams to change the storage driver without rebuilding the agent loop, although storage retention and access policies still need attention in the chosen implementation.
For workflows beyond one agent interaction, the project supplies two additional structures:
- Pipeline chains prompt templates, agents, structured output and application callables, with retry and fallback support.
- Graph supports branching, loops, human pauses, resumption in another process and fan-out work.
Graph branches can run inline or be handled by workers through cron, a queue or the command line. For PHP applications serving web requests, that matters: a lengthy agent workflow need not remain attached to one browser request. Teams would still need to arrange the worker infrastructure.
I would treat the 20-iteration default as a useful stop condition, not a spending budget. It limits loop iterations; it does not specify a maximum token bill or the cost of an individual tool operation.
Framework Adapters and Provider Selection
phpClaw lists adapters for Laravel, Symfony, WordPress, Drupal, Magento, Joomla, OpenCart and PrestaShop. The core has no framework dependency, so the documented architecture also leaves room for standalone PHP applications. These are project-listed integrations, not a comparison of adapter completeness or maturity. (GitHub README)
The provider builder checks environment variables in a fixed order and selects the first one it finds:
| Priority | Provider | Environment Variable |
|---|---|---|
| 1 | Anthropic | ANTHROPIC_API_KEY |
| 2 | OpenAI | OPENAI_API_KEY |
| 3 | Groq | GROQ_API_KEY |
| 4 | Gemini | GEMINI_API_KEY |
| 5 | Mistral | MISTRAL_API_KEY |
| 6 | DeepSeek | DEEPSEEK_API_KEY |
| 7 | Ollama | OLLAMA_HOST |
The runtime also supports a custom OpenAI-compatible endpoint, explicitly selected with PHPCLAW_PROVIDER=custom. The README documents ->provider and ->model for choosing a provider and model in application code.
That automatic selection is convenient for a small example, but the precedence deserves attention in shared environments. If both Anthropic and OpenAI credentials are present, the documented order selects Anthropic first. I’d make provider and model selection explicit in deployed applications so an unrelated environment change cannot silently alter the intended choice.
A common runtime interface also should not be read as identical capabilities across every backend. The README specifically associates prompt caching and extended thinking with Anthropic or Claude. Teams relying on those features should check their selected provider’s support.
phpClaw additionally bundles an MCP server for exposing application tools to Claude Desktop and Claude Code. That extends the same tool-building work to external AI clients, making tool permissions important beyond the application’s own chat interface.
Eight Default Guards Are One Part of the Boundary
The README lists these eight enabled-by-default guard categories:
- Prompt injection
- Personally identifiable information, or PII
- Code injection
- Unicode
- Homoglyph
- Role-switch
- Destructive SQL
- Message length
The overview names the guard categories, but it does not provide effectiveness measurements or enough detail to judge every detection rule and threshold. The supplied evidence includes no independent security audit. These are documented project controls, not independently verified protection results.
The more useful architectural detail is that phpClaw describes controls at several different boundaries.
Tool Results and Model Output Have Separate Controls
The project says ToolOutputGuard sanitizes tool results unconditionally and sits outside the guard registry. That distinction matters because data returned by a tool can itself contain instructions: a fetched page, log entry or database field may carry text intended to redirect an agent.
The README separately says model-output sanitization is enabled by default and can be disabled with ->sanitiseOutput(false). Rate limiting is another separate control, but it is opt-in, not one of the eight defaults.
This separation is worth preserving when evaluating the project. Input checks, tool-result processing and output handling address different points in an agent’s execution path. Counting them all as a single prompt filter would obscure how the runtime is designed.
Shell, HTTP and File Tools Restrict Their Own Reach
The documented tool controls go beyond examining messages:
| Tool | Documented Restriction |
|---|---|
ShellTool | Requires a command allowlist and retains a hard-coded blocklist that cannot be overridden |
HttpTool | Validates resolved IP addresses, addressing a DNS-rebinding gap left by hostname-only checks |
FileReadTool and FileWriteTool | Restrict access to a workspace and refuse sensitive paths and extensions |
Frequently Asked Questions
4 questions
1What Is phpClaw?
phpClaw is an MIT-licensed PHP agent runtime that bundles a ReAct loop, tools, pluggable memory, security guards and framework adapters.
