[FEATURE]

Resolved 💬 3 comments Opened May 8, 2026 by abarring-pinc Closed May 12, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

PHP is absent from the Cowork sandbox image, making it impossible to work with one of the most widely deployed server-side languages in the world. WordPress powers ~43% of all websites, Laravel and Symfony drive countless enterprise applications, and countless legacy codebases are PHP-based. Users who bring these projects into Cowork hit a hard wall — the sandbox can read their files, but the moment Claude tries to lint, test, run, or debug any PHP code, there is nothing to execute it. This silently excludes a massive segment of real-world development work from Cowork's otherwise impressive capabilities.

Proposed Solution

Pre-install PHP (8.2+ recommended, as it is the current stable LTS line) in the Cowork sandbox image alongside the existing Python runtime. The minimum viable set would be:

  • php-cli — core interpreter
  • Common bundled extensions: mbstring, curl, json, xml, zip, pdo, sqlite3
  • composer — the PHP ecosystem's package manager, equivalent to pip for Python

Allowlisting packagist.org and repo.packagist.org in the sandbox proxy (mirroring how pypi.org is already permitted) would make Composer functional and bring PHP's tooling on par with Python's out-of-the-box experience.

Alternative Solutions

  1. Partial pre-install (php-cli only, no Composer): Even a bare php -r interpreter would unblock script execution and static analysis. Composer access could be added in a follow-up once the baseline is validated.
  2. User-configurable sandbox packages: A broader solution would let users declare additional apt packages in a cowork.json or similar config file. PHP would be the first proof-of-concept, but this pattern would also resolve similar gaps for Ruby, Go, Rust, etc. without requiring a separate image build per language.
  3. Escape-hatch documentation: As a stopgap, documenting how users can invoke a host-side PHP binary via the existing sandbox escape-hatch mechanism would at least unblock power users while the image change is scheduled.

Priority

High - Significant impact on productivity

Feature Category

API and model interactions

Use Case Example

A developer brings a Laravel project into Cowork and asks Claude to refactor a service class and run the test suite. Claude can read and edit the PHP files perfectly — but php artisan test fails immediately because php is not found in PATH. The same session, Claude runs a Python script without issue. The asymmetry is jarring and makes Cowork feel incomplete for back-end web development. With PHP pre-installed, Claude could execute composer install, run php artisan commands, execute unit tests via PHPUnit, and validate syntax with php -l — turning Cowork into a genuinely capable PHP development environment.

Additional Context

PHP consistently ranks in the top 5–8 languages on developer surveys (Stack Overflow 2024 places it at ~20% usage). The Cowork sandbox already pre-installs Python, Node.js tooling is partially addressed via the npm allowlist discussion in #43334, and Java/JVM support has been requested separately. PHP is the most glaring omission for web-focused developers. A single apt-get install php8.2-cli php8.2-mbstring php8.2-curl php8.2-xml php8.2-zip php8.2-sqlite3 composer line in the sandbox image Dockerfile would resolve this for the majority of PHP workflows with minimal image size impact (~60–80 MB). Given that Python (~30 MB) is already included, this is a proportionate addition for a language with comparable adoption.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗