| Name | Modified | Size | Downloads / Week |
|---|---|---|---|
| Parent folder | |||
| README.md | < 20 hours ago | 9.7 kB | |
| v1.11.4 source code.tar.gz | < 20 hours ago | 3.6 MB | |
| v1.11.4 source code.zip | < 20 hours ago | 4.2 MB | |
| Totals: 3 Items | 7.8 MB | 0 | |
v1.11.4 — More Reliable Long-Running Tasks, Tool Runtime, and Feishu Group Collaboration
v1.11.4 focuses on sustained execution in real-world workflows. Agents can preserve context, recover execution, and deliver results more reliably across Feishu groups, Direct Chat, scheduled tasks, and long-running Tool calls, while Session and Tenant isolation boundaries are further strengthened.
What's New and Improved
Feishu Group Collaboration and Approvals
- Proactive group discovery and targeted delivery: Authorized Feishu groups can be discovered and selected as Schedule or Trigger targets before sending a message to an Agent. Group identifiers remain resolved server-side according to Tenant, Agent, and authorization relationships; raw
chat_idvalues are not exposed to the model. - Quiet group listening: Agents can follow group context and respond only when a message genuinely requires a reply. Messages that need no response do not create noise or hold a public group Run indefinitely.
- More complete group context: Structured human
@mentions are preserved, stale read state no longer hides Sessions, and external group conversations remain visible in the correct conversation entry point. - New Feishu approval tools: Agents can look up approval definitions, upload attachments, create approvals, and query approval status. Write operations are bound to the current Tenant, Run, Tool receipt, and user confirmation, preventing stale confirmation or cross-task reuse.
- Clearer reply feedback: After confirming a reply, an Agent can add a lightweight reaction to the original Feishu group message. Reaction failures remain cosmetic and cannot block or duplicate the text reply.
Durable Runtime and Tool Execution
- Recoverable Tool call contracts: Tool identity, route, call identity, timeout, and execution result are fixed when a call is accepted and remain consistent across retries, Worker recovery, and Checkpoint replay, reducing duplicate execution and route drift.
- More reliable argument validation and repair: Advertised Tool Schemas are validated before Provider invocation. Repairable errors receive bounded feedback, while Runs that exhaust their repair budget fail clearly and release their execution lane instead of looping indefinitely.
- Explicit handling for unknown outcomes: MCP calls, asynchronous Tools, and external writes enter an explicit recovery path when they time out or have an unknown result. A timed-out call is no longer assumed to mean that no side effect occurred.
- Evidence-based completion gate: Before a task finishes, the Runtime checks whether the goal is supported by verifiable evidence. A normal semantic-evaluation failure cannot overwrite confirmed Tool facts.
- Complete Tool history: Tool calls, results, and totals remain available after long-task compaction, history pagination, and Session switching.
Session-Isolated Sandboxes and Long-Running Workspaces
- Session-level output isolation: Code execution and file writes occur in isolated Session workspaces. Tenant and destination paths are validated at publication time to prevent one conversation from overwriting another conversation's artifacts.
- One coherent workspace for long Skill Runs: An Agent Loop reuses its sandbox and Skill snapshot, allowing an in-Run Skill repair to continue without context drift caused by compaction or rematerialization.
- Safer artifact publication: Workspace changes are validated before publication. Identical content is accepted idempotently, and concurrent conflicts retain diagnostic evidence. A workspace publication failure no longer suppresses an already generated chat response.
- More practical Code Executor defaults:
python3is supported consistently. The default execution timeout is now 180 seconds, with a default maximum of 300 seconds; explicit custom settings remain authoritative.
Chat and Task Visibility
- Restored Web Chat streaming: Only persisted, recoverable text is streamed. After a page refresh, network transition, or Worker handoff, the final response can still be restored from the same source of truth.
- Improved Direct Chat history navigation: History is paginated by complete folded Tool Turns, additional pages load at the top edge, and the visible position remains anchored when older messages are inserted. Live auto-follow no longer competes with history pagination.
- Strict Session state isolation: Run state, delayed events, controls, and Tool cards remain attached to their owning Session. Background tasks continue after switching conversations and display their results in the correct place.
Scheduling, Deployment, and Platform Foundations
- Schedules and Triggers share one scheduled occurrence: Timezone handling, Cron evaluation, queueing, idempotency keys, persistence, and Runtime Intake use the same occurrence, reducing duplicate execution and incorrectly timed triggers.
- Vercel deployments wait for an authoritative terminal state: Deployment operations track the exact Deployment and settle only after the Provider reports an authoritative state such as
READY,ERROR, orCANCELED. - More stable default Agent initialization: Deleting, stopping, or renaming the default Agent no longer creates unintended duplicates. Initialization remains one-time and recoverable.
- Stricter multi-tenant data boundaries: APIs, DAOs, organization data, model configuration, Tool history, and enterprise information consistently enforce Tenant Scope. Required backfills and migration convergence prevent cross-tenant reads and hidden historical records.
- Improved release observability: Post-release health-check results can be delivered through Feishu notifications. Database pools, API Workers, and slow-login thresholds can also be tuned for deployment scale.
Bug Fixes
- Fixed long-running tasks becoming unable to continue after context compaction, oversized Tool results, or truncated model output.
- Fixed Runs remaining active after exhausting the Tool repair budget, as well as waiting states failing to release their execution lane.
- Fixed Gemini Tool Results being paired with the wrong Assistant Turn and improved recovery from unknown Provider failures.
- Fixed long-running Vercel
BUILDINGstates being marked as failed too early and inconsistent settlement after status-read failures. - Fixed sandbox CAS conflicts during concurrent publication, isolated output counting against input quotas, and workspaces being released too early inside an Agent Loop.
- Fixed group Sessions, Tool history, and enterprise information becoming hidden after switching Tenants, as well as WebSockets using the wrong Tenant Scope.
- Fixed Direct Chat history failing to load at the top edge, long Tool Turns being split across pages, scroll jumps after pagination, and background Tool cards disappearing.
- Fixed stale Feishu group read markers hiding Sessions, public-group waiting states consuming unrelated messages, and duplicate event-creation risk after calendar contact lookup.
- Fixed Bubblewrap compatibility on CentOS 7 and Linux 3.10 and added safe proxy propagation into isolated sandboxes.
- Fixed duplicate-column failures during fresh-database migration and converged the v1.11.4 Runtime, Tenant, and Tool migrations onto a single Alembic Head.
Upgrade Guide
Database migrations run automatically during application startup. No manual Alembic command is required. Back up the database and persistent files before upgrading production.
Docker
:::bash
git fetch --tags
git checkout v1.11.4
cd deploy
docker compose up -d --build
docker compose ps
docker compose logs -f --tail=200 backend frontend
Wait until the API, Runtime Worker, Scheduler, and channel services are healthy before reopening production traffic.
Source Deployment
:::bash
git fetch --tags
git checkout v1.11.4
cd backend
pip install -r requirements.txt
cd ../frontend
npm install --legacy-peer-deps
npm run build
cd ..
systemctl restart clawith.target
Kubernetes / Helm
Update every Clawith service to the v1.11.4 image, then run:
:::bash
helm upgrade clawith helm/clawith/ -f values.yaml
kubectl rollout status deploy/clawith-api
kubectl rollout status deploy/clawith-worker
Notes
- Keep versions aligned: The Backend API, Runtime Worker, Scheduler, channel services, and frontend should use the same v1.11.4 build to avoid Runtime or Tool contract mismatches.
- Automatic migrations: Confirm in startup logs that database migration completed and only one latest Head remains. Do not start multiple old and new instances that can run migrations concurrently.
- Feishu permissions: Existing Feishu applications that use group reply reactions or approval capabilities must have the corresponding permissions approved by an administrator. Missing permissions do not affect ordinary text replies but will limit those capabilities.
- Sandbox configuration:
SANDBOX_DEFAULT_TIMEOUTnow defaults to 180 seconds andSANDBOX_MAX_TIMEOUTto 300 seconds. Review existing Tenant- and Agent-level Tool settings during the upgrade; explicit custom values are preserved. - Proxy configuration: For sandbox tasks that require controlled network access, use the dedicated
SANDBOX_HTTP_PROXY,SANDBOX_HTTPS_PROXY, andSANDBOX_NO_PROXYsettings. Avoid exposing unnecessary internal network addresses to the sandbox.
Thank you to all contributors and community members for testing, feedback, and improvements throughout this release.