Replace shell export statements with Python os.environ in all Python code blocks.
This provides a more Pythonic way to set environment variables.
Changes:
- docs/content/docs/get-started/quickstart.mdx: Update Cloud Sandbox, CUA VLM Router, and BYOK examples
- docs/content/docs/agent-sdk/supported-model-providers/cua-vlm-router.mdx: Update migration examples
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
When bumping cua-computer, we publish both packages. However, since cua-agent
depends on cua-computer, we should publish computer FIRST, then agent. This
ensures the new computer version is available on PyPI before agent (which
depends on it) is published.
Changes:
- Reordered jobs: publish-computer before publish-agent
- Added publish-computer to publish-agent's needs list
- Updated publish-agent condition to use always() with explicit result checks
- When service is cua-agent: publishes immediately
- When service is cua-computer: waits for publish-computer to succeed first
Job execution order:
1. bump-version (bumps versions, pushes to git)
2. publish-computer (only when service == cua-computer)
3. publish-agent (waits for computer if service == cua-computer)
This prevents dependency errors where agent might be published before the
computer version it depends on is available on PyPI.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
This PR addresses two issues:
1. **Fix version detection in pypi-publish-computer workflow**
- Updated to match the pattern from PR #598 for pypi-publish-agent
- Check inputs.version first (works for workflow_call regardless of event_name)
- Add debug output to help troubleshoot version detection issues
- Proper handling of all three trigger types: workflow_call, workflow_dispatch, push
2. **Publish both packages when bumping cua-computer**
- When bumping cua-computer, we bump both cua-computer and cua-agent versions
(since cua-agent depends on cua-computer: "cua-computer>=0.4.0,<0.5.0")
- Updated publish-agent job to trigger for both 'cua-agent' and 'cua-computer' services
- This ensures version consistency between the two packages
**Behavior:**
- When bumping `cua-agent`: publishes cua-agent only
- When bumping `cua-computer`: publishes BOTH cua-computer AND cua-agent
This maintains version consistency and ensures users can install the latest
versions of both packages together without dependency conflicts.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
When bumping cua-computer, the workflow was incorrectly publishing cua-agent
instead of cua-computer to PyPI. This was because the publish-agent job had a
condition that triggered for both cua-agent and cua-computer services.
Changes:
- Added computer_version output to capture the bumped computer version
- Changed publish-agent condition to only trigger for cua-agent service
- Added new publish-computer job that triggers for cua-computer service
- publish-computer job calls pypi-publish-computer.yml workflow
Now when bumping cua-computer:
- Bumps cua-computer version (as before)
- Also bumps cua-agent version to maintain dependency sync (as before)
- Publishes cua-computer to PyPI (fixed!)
- Does NOT publish cua-agent to PyPI (fixed!)
Fixes: https://github.com/trycua/cua/actions/runs/19512484987🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Previously, users had to explicitly read the CUA_API_KEY environment variable
and pass it to the Computer/CloudProvider constructor. This change makes the
API key parameter optional and automatically reads from the CUA_API_KEY
environment variable if not provided.
Changes:
- CloudProvider.__init__: Made api_key parameter optional, reads from CUA_API_KEY env var
- Computer.__init__: Added fallback to CUA_API_KEY env var for api_key parameter
- Updated documentation examples to show simplified usage without explicit api_key
- Updated cloud_api_examples.py to demonstrate the new simpler pattern
This provides a cleaner API while maintaining backward compatibility with
explicit api_key parameter passing.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
hud-python is an external package that isn't published to PyPI yet,
which was blocking installation of cua-agent[all]. This change:
- Removes hud-python==0.4.52 from the [all] extra dependencies
- Keeps the separate [hud] extra for users who have access to hud-python
- Allows pip install cua-agent[all] to work without dependency errors
The hud functionality remains available as an opt-in extra via:
pip install cua-agent[hud]
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Clean up all debug output added during investigation:
1. bump-version.yml:
- Removed "Verify agent version output" debug step
- Kept essential "Agent version: X.X.X" output
2. pypi-publish-agent.yml:
- Removed extensive "Version Determination Debug" output
- Simplified to show only "Agent version: X.X.X"
- Kept error messages for production debugging
- Removed "Verify prepare job outputs" debug step
3. pypi-reusable-publish.yml:
- Removed all debug output from "Verify version consistency"
- Kept the core version validation logic
- Script errors will still be visible if check fails
All workflows now have clean, production-ready logging while
maintaining the fixes from PR #598.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The bug: When pypi-publish-agent is called via workflow_call from
bump-version, github.event_name is "workflow_dispatch" (inherited
from parent), NOT "workflow_call". This caused the code to check
github.event.inputs.version (empty) instead of inputs.version (0.4.44).
The fix: Check inputs.version first, before checking event_name.
This works correctly for:
- workflow_call: uses inputs.version
- Tag push: extracts from tag
- workflow_dispatch with version param: uses inputs.version
- workflow_dispatch event UI: uses event.inputs.version
Debug output showed:
- Event name: workflow_dispatch
- Input version: 0.4.44 (correct!)
- Workflow dispatch version: (empty)
- Final VERSION= (bug - used wrong source)
Now it will use inputs.version first, giving VERSION=0.4.44.
Fixes: https://github.com/trycua/cua/actions/runs/19483269380🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Added debug logging at every stage of version passing to identify
where the version parameter is being lost:
1. bump-version job: Verify agent_version output is set correctly
2. pypi-publish-agent prepare job: Show inputs.version and verify
the get-version step output
3. pypi-reusable-publish: Already has debug showing empty version
Debug output will show:
- Event name and workflow trigger type
- Input version values at each stage
- Step output values
- Final version passed to reusable workflow
This will pinpoint exactly where the version parameter becomes empty
in the workflow_call chain.
Related: Previous debug showed "Expected version: " (empty)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
