4 ms·
What do you mean? Even Claude for Web can do the full compile edit cycle. It runs Debian and apt installs stuff on demand and can run anything its Debian has.
by delaminator 9mo ago
What do you mean?
Even Claude for Web can do the full compile edit cycle.
It runs Debian and apt installs stuff on demand and can run anything its Debian has.
I built a Chrome extension so Claude can get the full rendered DOM via a socket for web stuff.
Why do you think it can’t?
Are you perhaps using Claude Chatbot?
Claude Code will run anything you instruct it to.
I have to tell it to stop more than to start!
- aurareturn 9mo agoSo you had to build a Chrome extension for Claude so it can see its changes? Can Claude Code open Chrome to test its changes by default? No, not running chatbot. Running Claude Code CLI/Codex CLI.
- delaminator 9mo agoI didn't have to no. It can run curl and get whatever HTML was served. But how else would Claude see the live DOM ? The only way is through something running in the browser at runtime. And yes, Google Chrome added an MCP into Chrome for doing it but I use Vivaldi. When coding manually how would you check your code was working when it came to serving HTML? Are you telling me your Claude / Codex cannot run curl to look at what was served? If you need help with something you can ask, no need to be brusque.
- aurareturn 9mo agoWhy can't it just open the changes in Chrome and check it?
- delaminator 9mo agoYou mean like this? chrome --headless --dump-dom "https://example.com" > dom.html
- aurareturn 9mo agoNo. I don't need it to generate the html. I need it to render the service and check as well as clicking on the feature it built to test it.
- Kim_Bruning 8mo agoI've seen claude --chrome , but there's also at least 2 mcps that can puppeteer chrome. I've been using chrome-devtools fwiw
- delaminator 9mo agoI'm back at my desk now, here's something from my current Claude session of it writing and running code. Are you saying yours cannot do this? Nawin.Auth is running on 567. Let me write a quick test to capture exactly what bytes Nawin.Auth sends vs Crabbit (on 5670): ● Write(/tmp/compare_auth.py) ⎿ Wrote 83 lines to ../../../../tmp/compare_auth.py 1 #!/usr/bin/env python3 2 """Compare auth server responses byte-by-byte""" 3 import socket 4 5 def test_auth(host, port, name): 6 print(f"\n=== Testing {name} on {host}:{port} ===") 7 8 # Build AuthTreq request (141 bytes) 9 # type[1] + authid[28] + authdom[48] + chal[8] + hostid[28] + uid[28] 10 request = bytearray(141) … +73 lines (ctrl+o to expand) ● Bash(sudo lsof -i :5670 2>/dev/null | head -3) ⎿ COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME run-auth- 95646 root 9u IPv4 139735 0t0 TCP \*:5670 (LISTEN) ● Bash(python3 /tmp/compare_auth.py 2>&1) ⎿ === Testing Nawin.Auth on 127.0.0.1:567 === Request (141 bytes): Hex: 01676c656e6461000000000000000000000000000000000000000000006e6177696e00000000000000 … +53 lines (ctrl+o to expand) ● Both send 145 bytes, same format! Differences are only in the random session keys (bytes 64-72 and 136-144). The ticket encryption is identical.
- aurareturn 9mo agoIt looks like it can execute scripts. How about browser testing to verify?