Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I had a preview of this over the weekend, notes here plus some example PRs: https://simonwillison.net/2025/Oct/20/claude-code-for-web/

It's really solid. It's effectively a web (and native mobile) UI over Claude Code CLI, more specifically "claude --dangerously-skip-permissions".

Anthropic have recognized that Claude Code where you don't have to approve every step is massively more productive and interesting than the default, so it's worth investing a lot of resources in sandboxing.



It’s interesting because I’ve slowly arrived at the opposite conclusion: for much of my practical day to day work, using CC with “allow edits” turned OFF results in a much better end product. I can correct it inline, I pseudo-review the code as it’s produced, etc etc. Codex is better for “fire and forget” features for sure. But Claude remains excellent at grokking intent for problems where you aren’t quite sure what you want to build yet or are highly opinionated. Mostly due to the fact it’s faster and the iteration loop is faster.


That approach should work well for projects where you are directly working on the code in tandem with Claude, but a lot of my own uses are much more research oriented. I like sending Claude Code off on a mission figure out how to do something.

Here's an example from this morning, getting CUDA working on a NVIDIA Spark: https://simonwillison.net/2025/Oct/20/deepseek-ocr-claude-co...

I have a few more in https://github.com/simonw/research


Very fair. Interesting how much feedback on models/tools is different right now depending on what you're doing.


so hey by the way, have you discovered Wispr Flow or something similar so you can talk to your computer like Scotty does?


Yeah I've tried it a bit it's not a habit for me yet.

I write code on my phone a lot using ChatGPT voice mode though!


Here's what I did to make voice (now WisprFlow, before Superwhisper) a habit:

  1. Install Karabiner-Elements, a free macOS keyboard remapper[0]
  2. Map F19 -> F5 (mic button) in Karabiner-Elements
  3. Choose F19 as the voice hotkey in your voice app
And now you can use the handy F5 mic button on your Apple keyboard. WisprFlow automatically has it set for:

  - press and hold to talk
  - double tap for indeterminate listening until you f5/esc
That workflow alone, of using the f5 key and switching between the two modes of speaking (holding or double-tap), has freed up a not insignificant part of my working memory. Turning abstract thoughts into text is higher cost than turning them into voice.

I predict individual offices[1] will be more popular as a choice for startups.

[0]: https://karabiner-elements.pqrs.org

[1]: https://queue.acm.org/detail.cfm?id=1281887


fwiw, I use the fn/international key at the bottom left of the keyboard. it's easier to locate and I (a privilege I enjoy because I rarely use diacritics) barely use it for anything else.


I also use voice mode a lot, I find it's really useful for talking to while you're shaping an idea or an approach, then asking it to summarise the decisions you've made. Essentially rubber ducking.


It slows it down far too much for me. What I've found after swithcing to --dangerously-skip-permissions is that while the intermediate work product is often total junk, when I then start writing a message to tell Claude to switch approach, a large proportion of the time it has figured that out by itself before I'm finished writing the message.

So increasingly I let it run, and then review when it stops, and then I give it a proper review, and let it run until it stops again. It wastes far less of my time, and finishes new code much faster. At least for the things I've made it do.


Personally I just prefer setting it to TDD. If the test cases are what I want, and the code passes the tests, all's good.


Agreed. I use CC a lot for exploratory work. It's great with fast iteration for throwaway code.


> it's worth investing a lot of resources in sandboxing.

I tend to agree. There’s an opportunity to make it easy to have Claude be able to test out workflows/software within Debian, RPM, Windows, etc… container and VM sandboxes. This could be helpful for users that want to release code on multiple platforms and help their own training and testing, which they seem to be heavily invested in given all the “How Am I doing?” prompts we’re getting.


Do you have a practical sense of the level of mischief possible in the sandbox? It seems like a game of regexp whack-a-mole to me, which seems like a predictable recipe for decades of security problems. Allow- and deny-lists for files and domains seem about as secure as backslash-escaping user input before passing it to the shell.


If you configure it with the "no network access" environment there's nothing bad that can happen. Worst is you end up wasting a bunch of CPU cycles in a container somewhere in Anthropic's infrastructure.

Their "restricted network access" setting looks questionable to me - it allow-lists a LOT of stuff: https://docs.claude.com/en/docs/claude-code/claude-code-on-t...

If you configure your own allow-list you can restrict to just domains that you trust - which is enforced by a separate HTTP/HTTPS proxy, described here: https://docs.claude.com/en/docs/claude-code/claude-code-on-t...


How do you run a remote LLM with no network access?


OpenAI Codex, Claude Code for web and Gemini Jules have all managed that.

You use firewalls to prevent code running inside the container from opening network connections to anywhere else. The harness that surrounds it can still be made accessible via the network.


great points @simonw - I, incredibly, haven't ever tried --dangerously-skip-permissions yet for any "real" projects. I generally find that it stops itself for good reason.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: