PicoClaw
PicoClaw repairs Slack upload metadata while OAuth throttling stays opaque
PicoClaw proposes setting Slack FileSize during media uploads while a fresh report says Antigravity returns a generic 429 despite valid OAuth scopes and successful model discovery. An older Web UI lockfile repair remains open, showing delivery, provider and packaging friction in one small runtime.
sipeed/picoclaw PR #3340 is the inspected primary source: “fix(slack): set FileSize on media upload params.” The related records below were inspected as supporting context rather than independent confirmation.
The facts
- sipeed/picoclaw PR #3340 was created 2026-08-17T19:43:12Z and was open at inspection; its title is “fix(slack): set FileSize on media upload params.” - sipeed/picoclaw issue #3339 was created 2026-08-17T02:23:21Z and was open at inspection; its title is “[Bug] Antigravity generation returns generic 429 despite valid OAuth scopes and successful model discovery.” - sipeed/picoclaw PR #3318 was created 2026-08-05T23:04:11Z and was open at inspection; its title is “fix(web): repair unparseable pnpm-lock.yaml.” - The repository reported 29868 stars, 49 open issues, default branch main, and last push 2026-08-14T18:19:48Z. - The latest tagged-release baseline checked was nightly published 2026-07-02T01:26:53Z.
What changed
sipeed/picoclaw PR #3340 reports: Description SendMedia built slack.UploadFileParameters without FileSize, leaving it at zero-value. slack-go v0.23.1 rejects this before any network call because the files.upload.v2 flow requires the length upfront in files.getUploadURLExternal, and the SDK does not derive it from the File path. Every Slack media upload failed with "file.upload.v2: file size cannot be 0". Stat the resolved media file and pass its size. Also classify file.upload.v2 validation errors as ErrSendFailed instead of ErrTemporary, since they are deterministic and the previous mapping triggered three pointless retries per attempt. Regression from the slack-go 0.17.3 -> 0.23.0 bump (#2802): the legacy files.upload endpoint did not require a size. slack_test.go did not catch it because it mocks uploadFileFn, bypassing SDK validation. Type of Change [x] Bug fix (non-breaking change which fixes an issue) [ ] New feature (non-breaking change which adds functionality) [ ] Documentation update [ ] Code refactoring (no functional changes, no api changes) AI Code Generation [ ] Fully AI-generated (100% AI, 0% Human) [x] Mostly AI-generated (AI draft, Human verified/modified) [ ] Mostly Human-written (Human lead, AI assisted or none) Related Issue Fixes #3338 Technical Context (Skip for Docs) **Reference URL:** slack-go v0.23.1 validation guard: https://github.com/slack-go/slack/blob/v0.23.1/files.go#L547 Slack files.getUploadURLExternal (requires length): https://api.slack.com/methods/files.getUploadURLExternal
sipeed/picoclaw issue #3339 reports: Summary Google Antigravity authentication and model discovery work correctly, but every generation request returns: The response contains no quotaResetDelay or other quota metadata. The Antigravity UI appears to show available quota. Environment Redmi 8A with Termux Architecture: ARMv7 (armv7l) Go: go1.26.5 android/arm PicoClaw: nightly-49-g49183d7e Built using make build-linux-arm Binary: ELF 32-bit LSB executable, ARM, EABI5 Also reproduced with PicoClaw 0.2.9 Authentication OAuth succeeds using: PicoClaw successfully discovers the project and lists models with: A fresh access token contains all required scopes, including: The earlier ACCESS_TOKEN_SCOPE_INSUFFICIENT problem is therefore resolved. Models affected The same generic 429 occurs with: PicoClaw correctly resolves the local model aliases, but the initial generation request and automatic retries all fail. Expected result The authenticated model should generate a response. If this is genuine quota exhaustion, the response should ideally identify the affected quota and provide a reset time. Possible compatibility issue The provider calls: It appears to send: Could PicoClaw’s Antigravity request format, client fingerprint, metadata, headers or project routing be outdated? Please confirm whether the current implementation matches the official Antigravity client and whether this generic 429 has been reproduced with other accounts or platforms. I can provide additional sanitized debug logs if required.
sipeed/picoclaw PR #3318 reports: web/frontend/pnpm-lock.yaml lists semver@7.8.5 twice — once under packages:, once under snapshots:. YAML forbids duplicate mapping keys, so pnpm refuses the file: Reproducible on main (49183d7e) with the pinned pnpm: Scope This is build tooling, not runtime — the web UI builds and behaves identically either way. What it blocks: **Frozen installs**, so builds of the embedded web assets aren't reproducible. **pnpm audit**, which can't run at all, leaving the npm dependency tree unauditable. **Dependabot npm updates** for web/frontend, which can't apply to an unparseable lockfile. The fix Both duplicate blocks are byte-identical to the entries they repeat — same version, same integrity hash — so removing the second occurrence of each is lossless. 7 deletions, 0 insertions.** No package version changes. Why not regenerate the lockfile pnpm install --lockfile-only also fixes it, but pulls in roughly **80 unrelated package upgrades** — vite 8.0.16→8.2.0, eslint 10.4.1→10.8.0, radix-ui 1.4.3→1.6.7, chokidar 3.6.0→5.0.0 (major), plus a new lightningcss tree. That's a dependency upgrade rather than a corruption fix, and it seemed better left to your own judgement. Happy to send that version instead if you'd prefer it. Verification Using pnpm@10.33.0, the version pinned in package.json: Package set **identical** before and after — every name@version key diffed; the only difference is the removed duplicate. The
Why it matters
Tiny agents still inherit large-platform failure modes: typed upload metadata, provider-specific throttling and reproducible frontend dependencies all decide whether a feature works outside a demo. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.
Current
The primary record was open when captured on 2026-08-18. The tagged-release baseline was nightly published 2026-07-02T01:26:53Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/sipeed/picoclaw/pull/3340. Supporting records are https://github.com/sipeed/picoclaw/issues/3339 and https://github.com/sipeed/picoclaw/pull/3318. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Send complete media metadata, preserve provider error detail and retry boundaries, and make dependency lockfiles parseable in clean-install verification. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.