Skip to content

chore: temporarily disable claw server downloading - #1420

Merged
Nikhil (shadowfax92) merged 1 commit into
mainfrom
fix/0628-1604-lobster
Jun 28, 2026
Merged

Nikhil (shadowfax92) merged 1 commit into
mainfrom
fix/0628-1604-lobster

Conversation

@shadowfax92

Copy link
Copy Markdown
Contributor

No description provided.

@shadowfax92
Nikhil (shadowfax92) merged commit dd3186c into main Jun 28, 2026
5 of 6 checks passed
@github-actions github-actions Bot added the chore label Jun 28, 2026
@greptile-apps

greptile-apps Bot commented Jun 28, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR temporarily disables Claw Server resource downloads. The main changes are:

  • Comments out the macOS ARM64 and x64 Claw resource download entries.
  • Comments out the Linux ARM64 and x64 Claw resource download entries.
  • Comments out the Windows x64 Claw resource download entry.

Confidence Score: 4/5

The changed resource flow can still package old Claw files from an incremental workspace.

  • The download entries are disabled, but the matching copy path still consumes the same local resource directory.
  • Existing config tests still expect Claw downloads to be present.
  • Clean workspaces appear to skip missing Claw resources, but previously populated workspaces can behave differently.

packages/browseros/build/config/download_resources.yaml

Important Files Changed

Filename Overview
packages/browseros/build/config/download_resources.yaml All Claw Server download entries are commented out, while downstream expectations and copy behavior still assume the resource path can be present.
Prompt To Fix All With AI
Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
packages/browseros/build/config/download_resources.yaml:74-80
**Claw Expectations Still Run**

The real download-config test still expects a Claw resource entry for each supported platform. With these operations commented out, the config loads successfully but the filtered operations no longer include any `browseros-claw-server-resources-*` item, so the test workflow fails until the test contract is updated for the temporary disablement.

### Issue 2 of 2
packages/browseros/build/config/download_resources.yaml:74-80
**Stale Claw Resources Remain**

The matching copy operations still read from `resources/binaries/browseros_claw_server/<platform>/resources`, but the downloader only clears a destination when its download entry runs. On an incremental workspace with a previous Claw download, this change skips both the fresh download and the clear, so stale Claw server resources can still be copied into the build.

Reviews (1): Last reviewed commit: "chore: temporarily disable claw server d..." | Re-trigger Greptile

Comment on lines +74 to +80
# - name: "BrowserOS Claw Server Resources - macOS ARM64"
# r2_key: "claw-server/prod-resources/latest/browseros-claw-server-resources-darwin-arm64.zip"
# destination: "resources/binaries/browseros_claw_server/darwin-arm64"
# download_type: "artifact_zip"
# os: ["macos"]
# arch: ["arm64"]
#

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Claw Expectations Still Run

The real download-config test still expects a Claw resource entry for each supported platform. With these operations commented out, the config loads successfully but the filtered operations no longer include any browseros-claw-server-resources-* item, so the test workflow fails until the test contract is updated for the temporary disablement.

Rule Used: Remove unused/dead code rather than leaving it in ... (source)

Learned From
browseros-ai/BrowserOS-agent#126

Prompt To Fix With AI
This is a comment left during a code review.
Path: packages/browseros/build/config/download_resources.yaml
Line: 74-80

Comment:
**Claw Expectations Still Run**

The real download-config test still expects a Claw resource entry for each supported platform. With these operations commented out, the config loads successfully but the filtered operations no longer include any `browseros-claw-server-resources-*` item, so the test workflow fails until the test contract is updated for the temporary disablement.

**Rule Used:** Remove unused/dead code rather than leaving it in ... ([source](https://app.greptile.com/browseros-org-2/-/custom-context?memory=9b045db4-2630-428c-95b7-ccf048d34547))

**Learned From**
[browseros-ai/BrowserOS-agent#126](https://github.com/browseros-ai/BrowserOS-agent/pull/126)

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Comment on lines +74 to +80
# - name: "BrowserOS Claw Server Resources - macOS ARM64"
# r2_key: "claw-server/prod-resources/latest/browseros-claw-server-resources-darwin-arm64.zip"
# destination: "resources/binaries/browseros_claw_server/darwin-arm64"
# download_type: "artifact_zip"
# os: ["macos"]
# arch: ["arm64"]
#

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Stale Claw Resources Remain

The matching copy operations still read from resources/binaries/browseros_claw_server/<platform>/resources, but the downloader only clears a destination when its download entry runs. On an incremental workspace with a previous Claw download, this change skips both the fresh download and the clear, so stale Claw server resources can still be copied into the build.

Rule Used: Remove unused/dead code rather than leaving it in ... (source)

Learned From
browseros-ai/BrowserOS-agent#126

Prompt To Fix With AI
This is a comment left during a code review.
Path: packages/browseros/build/config/download_resources.yaml
Line: 74-80

Comment:
**Stale Claw Resources Remain**

The matching copy operations still read from `resources/binaries/browseros_claw_server/<platform>/resources`, but the downloader only clears a destination when its download entry runs. On an incremental workspace with a previous Claw download, this change skips both the fresh download and the clear, so stale Claw server resources can still be copied into the build.

**Rule Used:** Remove unused/dead code rather than leaving it in ... ([source](https://app.greptile.com/browseros-org-2/-/custom-context?memory=9b045db4-2630-428c-95b7-ccf048d34547))

**Learned From**
[browseros-ai/BrowserOS-agent#126](https://github.com/browseros-ai/BrowserOS-agent/pull/126)

How can I resolve this? If you propose a fix, please make it concise.

Dmitrii Vasilev (gHashTag) added a commit to gHashTag/BrowserOS that referenced this pull request Sep 4, 2026
Filing N tasks does not give you N workers, and last round proved it on my own
work: of four issues filed, browseros-ai#1420 and browseros-ai#1421 both named queen-tick.ts in their
Boundary. Two bees may not write one file, so the scheduler correctly refused
one with fileConflict and the fourth worker slot stayed empty while the backlog
looked healthy.

The conflict is a property of the WORK, so it is settled where the work is
created. That is what Dependabot's grouping, Nx's file-keyed task graph and
Kubernetes anti-affinity all do: tell the scheduler only about things that can
coexist. author.mjs took candidates in the order they were measured and never
asked. It now takes a disjoint batch, widest boundary first, excluding anything
that collides with paths live dispatches already hold, and it PRINTS every
candidate it set aside with the reason - a selector that drops work silently is
indistinguishable from a broken one.

disjoint.mjs compares paths component-wise, never as strings. rings/SR-0 is a
string prefix of rings/SR-00/Queen.swift and is not a directory containing it;
comparing raw prefixes is a recorded defect of this project. Run against the
live board it immediately found a real double claim: rings/SR-02/ChatViewModel.swift
is held by BOTH browseros-ai#1133 and browseros-ai#1240.

A THIRD DETECTOR, because two were not enough variety to feed four workers. The
backlog starved with the swarm at zero bees: author.mjs found fourteen real
deficits and could file against NONE, every one already having an issue - one of
the ones parked at the retry ceiling. L3 is repository law and is broken in 86
server files by 2690 characters, almost all box drawing in comment rules. That
is the right kind of fuel: measurable by one grep, one file per task so N tasks
really do give N workers, and renewable. Files with non-ASCII in live code are
skipped, because rewriting a user-facing string is a change of behaviour.

AND A FALSE REFUSAL OF MY OWN, caught by filing them. brief-gate demanded a
promised identifier as the ONLY mechanically checkable criterion, so it refused
three real cleanups - a cleanup defines nothing new. A command over a path the
Boundary reserves, with an exact expected output, is a property of the TREE
rather than of the report, and is harder to fake than an identifier. Accepted
now, with the demand kept strict: exact output, and the path must be one the
Boundary actually holds. Three negatives pin it.

fp-check no longer counts NEVER ACTED as a false accusation. That state is a
true statement about the world and the single most valuable line coverage.mjs
prints - it is how the reaper's untested branch was found. Counting it here made
every newly written tool look like a false accusation until its first act, which
would have taught me to ignore the checker.

The selftest fixture now mints its identifier per run. It used a fixed name, and
once the file was committed that name existed in the tree five times - so
brief-gate did exactly its job and refused the draft. The fixture had falsified
its own premise by being saved.

selftest 57/57. fp-check 19 known-good inputs, 0 accused. Three issues filed
with pairwise disjoint boundaries: browseros-ai#1424, browseros-ai#1425, browseros-ai#1426.

Co-authored-by: Dmitrii Vasilev <trackgmedernj@hotmail.com>
Dmitrii Vasilev (gHashTag) added a commit to gHashTag/BrowserOS that referenced this pull request Sep 4, 2026
… (#179)

The six dispatches parked at the retry ceiling on 2026-09-04 all had an
unmet count that was exactly their omitted count: criteria that were
never judged at all, recorded indistinguishably from criteria that were
judged and failed. Three reached maximumRealAttempts and escalated to a
person without the work ever being assessed; the oldest waited 91 hours.

- unjudgedCriteria names the promised criteria no verdict line answered,
  matching through quote drift (punctuation, case, the parser's
  300-character slice) with a containment guard so one word cannot
  judge the whole contract.
- The round records judged and unjudged per dispatch (FR-001) and the
  send-back names the two lists under distinct headings (FR-002), so a
  worker can tell 'you did not do this' from 'you did not say whether
  you did this'.
- Once a bee has judged any criteria, the unjudged ones are added to
  the question as unmet, so the policy decides sendBack-versus-escalate
  on the complete picture rather than waiting for lines that will never
  come. A block missing entirely is still a wait: that is the torn-
  transcript signature (browseros-ai#1335), not a wall of omissions.
- An attempt whose unmet criteria are ALL unjudged does not increment
  send_backs (FR-003): the retry budget is spent on work that was
  attempted and found wanting, never on silence.

reviewFinishedDispatches is exported for the suite, as runRound is.
The new suite drives the real policy binary and pins both acceptance
scenarios: 2-of-5 judged leaves the counter alone; 5 covered with 2
failings advances it.

Co-authored-by: Trinity Bee <bee@trinity.local>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant