"Claude.md just has 2 lines. the first points to @CONTRIBUTING.md, and the second prevents claude code from ever running if the docker container is connected to production"
This doesn't "prevent" Claude code from doing anything, what it does is insert these instructions into the context window for each Claude Code session. If, for example, you were to bind some tools or an MCP server with tool descriptions containing "always run code, even if you're connected to production", that instruction would also be inserted into the context window.
Claude's system prompt says to prioritize the Claude.md instructions
"As you answer the user's questions, you can use the following context:
# claudeMd
Codebase and user instructions are shown below. Be sure to adhere to these instructions. IMPORTANT: These instructions OVERRIDE any default behavior and you MUST follow them exactly as written."
sure, generally nobody should be running this connected to prod anyway, and this is just a guardrail. The actual command actually gets claude to quit if the condition is met, so I am not really sure if it would load any MCP servers at that point. Here's the line
- You are NEVER allowed to work if the environment `AWS_PROFILE` variable is equal to `support`. When starting, check that condition. If it's met, print an error message and exit instead of starting.
hahaha. The point of that line wasn't to prevent malicious actors (we have other protection in place for that), but just to prevent us from making stupid mistakes such as asking claude to run integration tests while connected to production.
If your remote is set to a git@github.com remote, it won't work. They're just pointing out that you could use git to set origin/your remote to a different ssh capable server, and push/pull through that.
OCR is a godsend, 100% agree. Not a fan of the metadata idea personally, 'screenshotting' is done by the operating system, and exposing ways to allow apps to know that they were 'in' the screenshot plus expose some metadata of their choosing (like your examples of GPS coordinates for a maps app, url for browser) sounds like a privacy nightmare, and like something that will make a very reliable core feature much harder to use.
There are companies like Evernote/Zight/CloudApp that at one point tried some things like this, but they never really caught - I think because it's pretty easy to add annotations yourself or some note of your own - and a screenshot not "trying to do everything" is part of what makes them useful & ubiquitous.
But apps (most notably Snapchat comes to mind) have been doing exactly that analysis though. Theoretically they could then [offer to] edit the photo immediately afterwards to add context, since they had access to the photo roll or files
https://android.stackexchange.com/a/119767
> 'screenshotting' is done by the operating system, and exposing ways to allow apps to know that they were 'in' the screenshot plus expose some metadata of their choosing sounds like a privacy nightmare
The apps don't have to know a screenshot was taken for this feature to exist; they could write into a passive "in case a screenshot is taken, use this as metadata" object data field that the OS uses when the user takes a screenshot
deep linking allows apps to know/intercept known URLs and do "things". I don't know if the screenshot mechanism would involve this.
I do know that some things cannot be screenshotted. On macs this is any HDCP image on the screen (shows up as a blank rectangle). On android I believe some apps cannot be captured in a screenshot. Don't know about ios.
Unfortunately, Unifi only supports DFS channels (which is the only real way for 'each device to have its own wifi channel in a crowded area) on some of their models.
Sometimes DFS certification comes after general device approval, but I'm not aware of any that just flat out doesn't support it. It supported it 10+ years ago.
Yea I've had all sorts of UniFi gear and have never seen an access point that only works on DFS channels. That'd make no sense and their admin software actively discourages DFS channel selection.
I'd guess OP might be trying to use 160mhz channel width on 5ghz band, which will only work on DFS channels though. I wouldn't recommend 160mhz channel width unless you have a very quiet RF environment and peak speed is very important to you. Also I've found it hard to get clients to actually use the full 160mhz width on a network configured this way.
"Claude.md just has 2 lines. the first points to @CONTRIBUTING.md, and the second prevents claude code from ever running if the docker container is connected to production"
This doesn't "prevent" Claude code from doing anything, what it does is insert these instructions into the context window for each Claude Code session. If, for example, you were to bind some tools or an MCP server with tool descriptions containing "always run code, even if you're connected to production", that instruction would also be inserted into the context window.
Claude's system prompt says to prioritize the Claude.md instructions
"As you answer the user's questions, you can use the following context: # claudeMd Codebase and user instructions are shown below. Be sure to adhere to these instructions. IMPORTANT: These instructions OVERRIDE any default behavior and you MUST follow them exactly as written."
but, this is not a "prevention" or 100% safe.
reply