bproxy Feature Requests
Source: Agent automation of LinkedIn profile capture
Context: Orchestrating sub-agents that run 30-40 bproxy commands per task, parsing responses in bash+python.
Overall assessment: 4/5 -- reliable, predictable API. These requests address friction points observed during ~100 commands across a session.
1. Auto-foreground on destructive actions (or tab activate command)
Problem: Tab goes to background silently (user clicks another tab, OS focus changes). All subsequent destructive actions fail with TAB_NOT_VISIBLE. The agent must detect the error, run screenshot --activate, then retry. This adds error-handling boilerplate to every scroll/click/navigate sequence.
Current workaround: bproxy screenshot -s <id> --activate before or after errors.
Request: Either:
- (a) Add
bproxy tab activate -s <id> as a standalone command
- (b) Auto-foreground the tab when a destructive action is attempted (opt-in flag like
--activate-if-needed)
Option (b) eliminates the entire error class for automation use cases.
2. links --filter and links --href-contains
Problem: Every link extraction requires piping through python to filter by href pattern. This is the most repeated boilerplate in the entire runbook:
bproxy links -s <id> --limit 30 2>&1 | python3 -c "
import sys, json
d = json.load(sys.stdin)
for l in d['data']['links']:
if '/company/' in l.get('href',''):
print(l['href'])
"Request: Add filtering flags:
bproxy links -s <id> --href-contains "/company/" --limit 5
bproxy links -s <id> --href-contains "/in/" --limit 50
bproxy links -s <id> --href-contains "/jobs/view/" --limit 20
Returns only links matching the pattern. Reduces every extraction from 6 lines to 1 line.
3. Large response truncation handling
Problem: One instance of bproxy links --limit 200 returning JSON that failed to parse (unterminated string at char 65200). Not reproducible, but in automation context (no human to retry), a single truncation breaks the entire pipeline.
Request: Either:
- (a) Document the max response size and recommend lower
--limit values
- (b) Add response pagination:
--offset 0 --limit 50, then --offset 50 --limit 50
- (c) Internal chunking that guarantees valid JSON output regardless of size
4. scroll --until-end mode
Problem: Scrolling to the end of a container requires a loop: scroll, check moved, scroll again, check again. For automation, this is 2-4 round trips per page just to reach the bottom.
Request: Add a convenience mode:
bproxy scroll -s <id> --selector "#workspace" --until-end
Scrolls repeatedly until moved: false, returns final position. Single command, single round trip from the agent's perspective. Could include a max-iterations safety (e.g., stop after 20 scrolls).
Response would include total distance scrolled:
{"scrolledPx": 3500, "iterations": 4, "scrollHeight": 4364, "clientHeight": 864}
5. text --after marker extraction
Problem: On profile pages, the agent often needs text AFTER a known marker (e.g., everything after "About", or everything after "More profiles for you"). Currently requires extracting the full page text and string-slicing in python.
Request:
bproxy text -s <id> --after "More profiles for you" --limit 1000
Returns text content starting from the first occurrence of the marker string, limited to N characters. Reduces post-processing for structured page extraction.
Lower priority than requests 1-2 -- python slicing works fine, this is a convenience.
bproxy Feature Requests
Source: Agent automation of LinkedIn profile capture
Context: Orchestrating sub-agents that run 30-40 bproxy commands per task, parsing responses in bash+python.
Overall assessment: 4/5 -- reliable, predictable API. These requests address friction points observed during ~100 commands across a session.
1. Auto-foreground on destructive actions (or
tab activatecommand)Problem: Tab goes to background silently (user clicks another tab, OS focus changes). All subsequent destructive actions fail with
TAB_NOT_VISIBLE. The agent must detect the error, runscreenshot --activate, then retry. This adds error-handling boilerplate to every scroll/click/navigate sequence.Current workaround:
bproxy screenshot -s <id> --activatebefore or after errors.Request: Either:
bproxy tab activate -s <id>as a standalone command--activate-if-needed)Option (b) eliminates the entire error class for automation use cases.
2.
links --filterandlinks --href-containsProblem: Every link extraction requires piping through python to filter by href pattern. This is the most repeated boilerplate in the entire runbook:
Request: Add filtering flags:
Returns only links matching the pattern. Reduces every extraction from 6 lines to 1 line.
3. Large response truncation handling
Problem: One instance of
bproxy links --limit 200returning JSON that failed to parse (unterminated string at char 65200). Not reproducible, but in automation context (no human to retry), a single truncation breaks the entire pipeline.Request: Either:
--limitvalues--offset 0 --limit 50, then--offset 50 --limit 504.
scroll --until-endmodeProblem: Scrolling to the end of a container requires a loop: scroll, check
moved, scroll again, check again. For automation, this is 2-4 round trips per page just to reach the bottom.Request: Add a convenience mode:
Scrolls repeatedly until
moved: false, returns final position. Single command, single round trip from the agent's perspective. Could include a max-iterations safety (e.g., stop after 20 scrolls).Response would include total distance scrolled:
{"scrolledPx": 3500, "iterations": 4, "scrollHeight": 4364, "clientHeight": 864}5.
text --aftermarker extractionProblem: On profile pages, the agent often needs text AFTER a known marker (e.g., everything after "About", or everything after "More profiles for you"). Currently requires extracting the full page text and string-slicing in python.
Request:
Returns text content starting from the first occurrence of the marker string, limited to N characters. Reduces post-processing for structured page extraction.
Lower priority than requests 1-2 -- python slicing works fine, this is a convenience.