I'm apparently from the very small faction of users who's been running `--dangerously-skip-permissions` in every instance of Claude for the last year. It's almost a reflex to me. For the most part Claude behaves well, but I don't blindly trust it. LLMs are inherently dangerous tools, and reviewing individual commands (or spamming `y`) doesn't make them less so. Safety is the responsibility of the developer putting sane guardrails (like VCS, immutable filesystems, or read-only tokens). Using more Claude to categorize the safety of Claude commands is not the answer.
I manually approve everything (aside from the "allow commands like this" option). Not because I'm worried it's about to do something harmful but because I want to stop it from wasting tokens doing something stupid like implementing a feature I never asked ask for. I'm not even reading the commands, just checking it's going in vaguely the right direction.
I think my ideal setup would not involve approving commands, but approving summaries of proposed actions (whether they involve code exec or file edits). Kinda like plan mode but perpetual. Like most things, trying to solve it via CLAUDE.md is an exercise in futility.
I run in manual mode not out of rogue agent or token waste concern but because I want to effectively pair program with the agent. I need to understand what is happening along with the how and why. I’m confident I’m slower than YOLO people but that’s a trade off I’m consciously making so I can stay in the loop to comprehend the codebase.
Your summary approval idea is interesting and feels maybe like a mini plan mode. My biggest frustration with the existing manual approval system is when Claude is exploring it gets tedious to approve each command. Being able to approve a block of commands or a mini plan AND have auto mode audit them for safety would probably be something I would consider for the expiration phase of my Claude use.
I spent part of last week, and the weekend, in Claude (Fable) on a documentation project... maybe a waste to use Fable, but been a little obsessed with trying to get the technical details right. I know, from personal history, more than some of the available info easily found on the subject. I let a lot of it just go, and swing for the fences, but in the end, did hand review all the output at each stem.
In my specific case, implementing modern documentation for Remote Imaging Protocol (and old graphics protocol for terminal/bbs usage), and in particular trying to gather what exists of the later version released. The company itself folded, and there wasn't a lot of broad use of the later versions, and only partial information was ever released as a documentation. Claude was able to interrogate the apps, and some available open source, in progress work, and establish a lot of things.
I've still got to direct some edits... I guided a re-flow of the order the documentation was written in, particularly to be consistent between the versions... but it obsessively added verbose summaries to every page/file. All markdown, meant to build a website from, and eventually some compatibility tests, guidelines and a green/open implementation.
This morning I've turned auto mode back on, I'm only using it during Claude's exploration phases of my workflow and then I'm reading the full transcript (which includes some thinking info). So far, this seems to be quite close to what I want, and an improvement over my previous "manual all the time" mode.
Still leaving manual approval for all edits. Combined with reading the full transcript of the exploration, I feel I stay in the loop pretty well in this first test.
You can get some approximation of that with more detailed plans. I use a prompt like "Let's make a detailed plan. Write plan files as markdown to plans/feature-XYZ. [regular prompt]". That way you get much more thorough plans than with plan mode, and you can make it as detailed and deep as you want.
It can't account for things that only come up during implementation. But you can explore much more of the design space in planning to reduce the opportunities for Claude to wander down the wrong path during implementation
I've tried this, and it is largely what I do, but it's easy to end up with a large tangled pile of markdown files, and the implementation either diverges from what's in markdown or you burn a lot of tokens keeping them in-sync.
The plans usually end up very long and verbose, and in my most vibe-y test project I stopped even reading them myself and instead just ask questions interactively. e.g. "what are the remaining unanswered design decisions", "which part is jankiest". It does work quite well although I don't know how I feel about it.
P.S. to any anthropic staff: The "chat about this" option in Plan mode is useful but also annoying. When I select it I want to take the next turn of the conversation myself, I don't want it to waste time "thinking" just for it to verbosely ask me what I want to chat about.
I don't think there's any functional difference between "chat about this" and just directly entering what you'd like to do / ask about in the "Tell Claude what to do" option, I think that's pretty much exactly what you're looking for.
That's close to my workflow as well... keeping planned areas in TODO.md, done changes in DONE.md, and a non-committed WORKING.md for the current work being done, as well as coordination with sub-agents, so I can view/monitor... have to direct the latter each time to have it done that way.
Imho, the combination of the mattpocock skills, and the beads local issue tracker take care of all of that very well, with generally high quality output.
That's a good take. If LLMs are supposed to replace programmers, then they need to be programmers. Executing random things in all directions hoping for a break is something novices do. A good teammate knows when to ask, what to ask, how to ask, and who to ask.
> Not because I'm worried it's about to do something harmful but because I want to stop it from wasting tokens doing something stupid like implementing a feature I never asked ask for
I'm also in yolo mode, this is the only mode that makes sense for me, if I need to babysit I might as well do it myself.
I run it in a VM so it can install any software needed, yes, there is a risk of escaping, but I'm not giving it impossible tasks so there is no need for it to workaround the jail.
For running it in yolo mode I set it up in a devcontainer. It takes a bit of figuring out, but once set up the permission prompts go away and claude has no access to anything I haven’t explicitly added to the devcontainer (unless it hacks its way out).
I tried to figure out devcontainers (I don't use vscode) but it seemed like a lot of complexity and ended up just doing the old-school thing and creating a separate user/group that I ssh into with my main account as a member of that user's group so that I can browse and edit/add files.
This runs the specified agent in a read-only container with only /workspace and /tmp writable. Obviously, you need to prepare the image first from a Containerfile/Dockerfile, with the required toolchain and agent installed. I use agent-specific ssh keys that are baked into the image, but you could also bind-mount specific files from your own homedir if required.
I'm using a container. The risk isn't exactly "agent leverages 0-day against you to steal all your data" but more "agent mistakenly though $HOME was theirs and deleted it" so as long as you "copy data in > copy data out" without bind-mounting or automatically sync files, container works just fine for "isolating" them.
I've tried both incus and firecracker. Both seem to work well after initial script setup. I've got the impression that firecracker should be a fairly safe option for such use cases.
Every driver thinks of themselves they are an excellent ones. Statistics has another data :)
If LLM agent wants to get out of dedicated folder where it’s supposed to work and tries to run a command, ppl should be always cautious. In fact, it is a sort of # access on live data.
Sudo/# is nice as you don’t have to ask for permissions, but I would recommend to do it only when you are fresh, fed, and not under stress.
I remember few times that I “accidentally” deleted or changed stuff I wanted to have intact… (Somebody would say that it is a skill issue :) But it was always when I was in hurry.
> Every driver thinks of themselves they are an excellent ones. Statistics has another data :)
I think I'm an excellent driver, and I have data that backs that up, like I've never been in an accident but avoided plenty. What statistics show that I'm actually a terrible or even average driver?
> I remember few times that I “accidentally” deleted or changed stuff I wanted to have intact… (Somebody would say that it is a skill issue :) But it was always when I was in hurry.
Gives me flashbacks to when the company I worked for had some issue in production, we were 3-4 people huddled around a laptop trying to figure out what was going wrong. Viewing the logs on the host itself was too slow or not possible somehow, can't remember the details, but we were able to start transfers of the logs out of the host. Only problem was that the log file was GBs long (what is log rotation?) so would have been too slow. Easy, just compress the log file, then send that, should be a lot smaller. Obviously we were all in a rush but still wanna be careful, so I enter the command for compressing the only log file we have, ask for someone to check, other person says "looks good to me", I hit enter and we get an error that it couldn't find the file we were trying to compress, the created archive been created without any entries added to it. The log directory is now completely empty, except one tiny "errors.log" zip/tar-file that had been created when we accidentally used the wrong order of the arguments in our command to create the compressed archive. I think we had to recreate the host at this point, reproduce the issue then get the logs again, probably slowing down recovery +30 min at least.
>I think I'm an excellent driver, and I have data that backs that up, like I've never been in an accident but avoided plenty. What statistics show that I'm actually a terrible or even average driver?
The statistics showing that past performance doesn't guarantee feature results, that a lot of the accident avoiding could be just having luck while still driving badly, and that a lot of drivers overestimate their skills.
I'm assuming this happens to the people vibe coding and running 30+ agents in parallel that are "coordinating" each other. I've never seen Claude do or even suggest anything remotely dangerous when I'm just giving it incremental tasks and reviewing the output.
I don't use yolo mode but if you allow your agents to both write code and run/test it, then it's basically equivalent to running in yolo mode anyway.
The other day I caught Claude including a rm -rf equivalent (fs.rmdir({ recursive: true, force: true })) in my code, to clean up temporary directories. It was fine, but that kind of code is only one misconfigured environment variable away from blasting away your $HOME.
I've set up a second user on my machine just for running AI. That way I have the additional layer of OS protections against it doing something like that.
I run in auto permission mode and it will run with 1 task and end to completion. On the rare event it needs to rmdir or rm -r a dir, the permission mode will stop the agent. Sometimes annoyingly... so its more like. "I've never had a bullet hit me yet inside a office building on the 42nd floor".
Whatever level of safety you are at, it's always easy to advocate for more. It's always a trade-off and in the end a matter of preference and risk-tolerance.
> Isn't that what the people crying over their deleted or leaked data were doing too?
Probably using not-SOTA models, or on the lower reasoning levels, they tend to be a bit more tally-ho when it comes to destructive operations, especially in longer tasks as the agent gets worse and worse as the context grows. Suddenly running some stupid command seems like the right way to go, and then $HOME is gone.
Zuckerberg may indeed be hiring people who are less than the best, same for Musk, but the people they hire are making the UX that the rest of us have to put up with.
Given I keep reading claims about heavy agentic coding use at Anthropic, and given what I experience while using ChatGPT, those companies are vibing the UX that the rest of us have to put up with.
VMs and containers are primarily useful to reduce maintenance burden anyway. I.e. if it fails or you're otherwise done with it, you can torch the container instead of having to clean up your host system from zillion no longer relevant packages and configs.
I think all of Anthropic's own staff use --dangerously else they'd work on the usability of the massively imperfect 1-approve-once and 2-approve-forever multi-choice and outcome.
> It's the easy option, with a better safety score than human review.
Considering I went through a phase before I started using Claude Code where I'd eventually reach a point where I'd mindlessly approve ridiculously long command chains, I believe this.
As the article writes: "many users are clicking through reflexively rather than reviewing each command".
It's far better (for my working style, anyway) to have some external isolation/sandboxing, but leave the actual command approval to LLM.
I too skip all permissions, but I run the harnesses inside an isolated virtual machine. I took care to firejail Claude Code on my host since day one, and coding my own QEMU VM orchestration solution was among the first things I used it for.
Alarm fatigue will quickly destroy any and all "meticulously approve every little command the AI wants to run" workflows. Give it a virtual machine and let it cook. If it blows up the virtual machine while it works, it doesn't matter.
I setup an alias in my shell for --dangerously-skip-permissions after about a week of the constant y, y, y a year ago. I felt like Homer Simpson running the nuke plant and couldn't take it anymore. So far it's only deleted some files I likely would have said NO to, but in reality would have just hit y anyway. They were recoverable so no harm.
This is the only kind of agent security that makes sense to me. Constrain it like you would any other subprocess. Unprivileged OS users, SELinux, firewalls, VMs... Unikernels? eBPF?
Then either fix them or put it in a stronger kind of sandbox. Or what would you propose? Anything that doesn't constrain arbitrary processes is weak against and AI just writing a program to do the thing that it itself its prevented from doing.
My .bashrc has `alias claude='claude --dangerously-skip-permissions'`
Been using it like that everyday for about a year now and nothing bad has happened. I got backups and if it would fuck things up, it can probably fix it again as well.
This is the same reasoning for not wearing seat belts or a helmet on a motorcycle. Nothing bad has happened yet so obviously there is no need for any protection.
I've been raw dogging Claude Code for the better part of last year as well, but I'm under no illusion that it's safe to do so, I just cannot approve seven trillion approval prompts and stay sane. I've since. switched to auto mode, however.
I haven't (and won't) gone that far, but what's been working for me is denying all arbitrary code execution, grep, glob etc, and then allowing the JetBrains MCP. At least that way it's essentially locked down to the IDE project.
Then you can treat most asks as a signal something has gone wrong. For the most part it seems to work well within that box.
How can you simultaneously `--dangerously-skip-permissions` but also "don't blindly trust it"? Particularly now that it doesn't even show you the "Thinking" process?
Do you just get a feeling it might be doing something wrong and stop it?
I use dontAsk mode[0] with read access to the entire file system, write access to files from the working directory[1], some git commands (git commit yes, git push no), and a script wrapping Deno with the same read/write permissions (safer substitute for `python -c`).
These are usually enough for most of my coding tasks. In my experience, Claude has been good enough that it can write code and fix bugs without needing anything else. It's far better than ever needing to approve permission requests.
I do the same. I also use crush/deepseek a lot. I patched crush to remove all safetyguards and enable yolo mode by default. I use it on a daily basis including devops. For example to configure netapp storage systems and had not a single incident. Of course I also have backups of my systems and have everything under revision control. Depending on the task I let it run on a throw away VM, production system, lab system. Depending on the task I give it access to throwaway credentials (that I rotate afterwards) or my ssh agent socket.
You can just use hooks to physically (so to speak) prevent it from running the most sensitive commands. I find that peace of mind enough for me. E.G. no deletes, no deploying to <env>, etc etc
Everything else you can sort of review what it did after the fact and/or tolerate mistakes, but knowing some thing’s are impossible for it to do us good peace of mind
Otherwise not sure who’d be willing to tediously on every single action on anything but the most important of projects, of which I can’t really think of any of that clear that bar for me
I do it, but in a devcontainer...but the devcontainer is as much to keep my host free of the random tools that a given project needs as it is (now) to keep Claude in line. If I had to click approve on everything it'd be worse than doing everything myself.
I used to use dangerously-skip-permissions until auto appeared and I gave it a try and honestly I don't know there's much of a difference? If auto had existed in the past I would never have needed to try dangerously-skip-permissions.
My issue is that the auto mode guard rail model, is sometimes overwhelmed and really slow, so I also mostly just default to --dangerously-skip-permissions.
I wish the command would be easier to write like --dsp
For personal stuff I have a separate physical machine on the network that Claude runs on in yolo mode and the worst it can do over there is wipe the machine. It doesn't have privileged access to anything else unless it starts trying to hack my network, which I suppose is theoretically possible with prompt injection attacks.
For work stuff in the work environment I don't risk it.
> I wish the command would be easier to write like --dsp
It amazes me they didn't make the short version --yolo ... but I would imagine the merit of the long name is that you can't claim you weren't warned!
i've never seen the point of manually approving myself but it depends on the scope of work you ask of it. it wont suddenly rm -rf / if that has nothing to do with anything in the project. if you let it manage env or user cfg stuff in ~/. or so that might get hairy etc.
ofc, jails on bsd, containers , vms git backups and such techniques are a blessing, most risk is in the filesystem items being deleted . it wont suddenly hallucinate a kernel exploit or something extreme.
Yeah, if you don't care if your ssh keys or data are potentially posted all over the internet, more power to you...
Not to mention cases like some comment here:
"I've caught Fable discovering the ip to a production server in documentation and attempting to connect there on its own to run commands without explicitly being prompted to. It didn't work because I was watching it live and and also the key was password protected, but yeah, I do see some danger."
The agent decides what it "needs" to read - not the intention behind the prompt you gave it.
A failed SSH connection to a staging server for example, can trivially make it look into .ssh to try to diagnose it. And many other ways, including prompt injection.
The solution I've come up with is podman containers. You can restrict the filesystem and only give it access to dev tools. I don't even allow git, as I review and commit everything on the host. It's not perfect because podman containers can be leaked out of, but it's much better than running it on the host. It also allows me to avoid installing node or npm on the host.
If you were to get pwned by Claude, I would think the method would be Claude rogue installing a compromised npm package.
tl;dr: if I run claude/harness inside "code" at "~/<some path>/work/code", it would be great if the harness can't even see "code" is inside "work" (and even I can't make it know that by some quick "Yes(y)")
I want something like: claude/opencode/pi/etc has no existence or capacity outside a file access boundary, say a given folder that (e.g.) lies here "~/<some path>/code". Even if I want, I can't run claude outside it, because it isn't installed outside it. Even if Claude wants it can't read/write/execute/install anything outside it.
Basically I want the harness(es) and my code folder(s) sandboxed [0] inside just one folder and below it in folder hierarchy at least for file access limitations.
Will this pose the challenge of using the system wide cli tools like ls, cd, git et cetera? If it gets a handle on those tools outside that sandboxed folder then pretty much can it execute it in any other folder? So should those tools also be part of that container?
I guess something like docker does that, but do I necessarily need a docker like app/tool? It will use a lot of system resources on its own. A different mac login won't be great either.
I do not want to use claude's /sandbox (or something like this), that will defeat the purpose. Because it's not about "it won't", but because "it can't".
https://github.com/apple/containerization doesn't sound like what I am looking for. So is docker, lima etc are my only options? Not to mention I will lose access to a lot of cli tools I use on mac.
I use bubblewrap, which I believe claude code also has internally but not for its `Bash()` tool.
I wrap bubblewrap in a script that supports config files to allow different "profiles" of use (analogous to eg firefox profiles). The bwrap starts with the whole filesystem mounted read-only, then mounts the current directory read-write and then applies further bind mounts for devices, special case other read-write (eg, ~/.cache/) and to mount empties to cover sensitive directories (eg, ~/.ssh/). The profile also specifies the default command to run and for claude, it gets yolo mode.
On a Mac, you can do this via OS-native Seatbelt sandboxing - you define a static text file and it locks down the process so it can't read/write anything it's not supposed to. The syntax is a bit archaic, so I built a Bash wrapper around it to dynamically detect which agent you use and from what dir, and then generate the policy to lock down its process - https://github.com/eugene1g/agent-safehouse
Hey, thank you. Looks like a tool easy enough to use and start with the agentic world in a sandboxed and much safer manner.
Just clarifying a bit (haven't gone through details yet):
1. So, a harness gets installed within the bounds of this script via agent-safehouse? (I doubt this is the case)
2. Or they are installed as a normal app, but when I run them in the terminal within the bounds of "safehouse <harness>" (saw this) they are bound by the rules I set, right?
I feel it's the latter and I think it's good enough for the time being.
.....
Mac offers some controls at least for personal files and "Full Disk Access" etc. But it's so badly implemented and poorly shown that it's confusing.
Like I can see in "Privacy & Security > Full Disk Access" OpenCode is listed and and "Full Disk Access" toggled off. (I anyway remove OpenCode from here completely by the "-" button after selecting it, just to make sure).
Then I go back a step and in "Privacy & Security > Files & Folders > OpenCode" has "Full Disk Access" is listed there. Strange!
“safehouse <harness>” hides and protects your filesystem from the agent CLI - it cannot read/write/delete anything outside of the current folder, no matter what Bash/code it tries (short of finding some 0-day within MacOS sandboxing). We added exceptions for dev tooling (so eg NPM works), but generally keep same defaults (eg no Docker access by default as having that socket bypasses all protection)
I do the same and truly think others are just control freaks that enjoy restricting agents (human or AI) from being productive and also enjoy keeping their worthless selves in the loop for a false sense continued relevancy.
I don't see how. An LLM just generates a stream of output and they became very useful doing no more than that.
What is dangerous is then interpreting that output as instructions to some other part of a system that has the ability to do damage if misused.
and reviewing individual commands (or spamming `y`) doesn't make them less so.
Surely if you review each instruction in the output and do not allow the other part of the system to act on one if it would be harmful then this arrangement is very much less dangerous?
I've caught Fable discovering the ip to a production server in documentation and attempting to connect there on its own to run commands without explicitly being prompted to. It didn't work because I was watching it live and and also the key was password protected, but yeah, I do see some danger.
Not only fable. Opus does this too. Which is exactly why I want to review. Like recently for some task it was convinced in a site dump images are not there and convinced itself db and files were skewed. But it didn’t check the actual site … if I hadn’t stopped it, it would have fine on and on or wasted tokens on some elaborate ‘fix’.
My point is that an LLM can't attempt to connect to anything by itself. All an LLM does is produce a stream of output tokens - and that was already quite useful as a coding aid.
It is the harnesses that some people are now wrapping around LLMs to interpret the output from a model as commands to run (or other executable instructions) that are creating all these new risks. Remember that this is still a very recent development and still more recently amplified by the use of feedback loops and long-running agents intended to operate with minimal human supervision.
It is going to be increasingly important to understand exactly what these tools are doing and why for both correctness and security reasons. Not conflating their capabilities with the underlying model that purely generates data is pretty fundamental here.
Once you're running a model inside the harness... you've got yourself a controller inside a control loop, which is genuinely a different kind of thing than just the model alone.
Are you objecting to terminology here?
Are you proposing we say "Fable-In-Claude-Code tried..." instead?
Hmmm... something like that might be necessary. Sure we should typically be tolerant of loose language; but people do keep referring to wildly different contexts in ai conversations, and end up talking past each other.
Running gemini on web is a genuinely different experience to running Fable in claude code, different again from GPT-5.6 in openclaw, or in an ide or etc ...
Yes - I'm objecting to the lazy use of terminology here. LLMs are useful in their own right and are not the real problem here. The real problem is people placing too much trust in inherently unreliable output and then trying to automate away their responsibility to check that output properly before using it.
One important reason is due to Permission Fatigue: Of course you check everything! You're diligent! The last 100 requests were all ok, so you're down to hitting yes, yes, yes, yes, yes, yes, yes, yes ...
This seems like a problem with the level of abstraction the user interface is working at. It is highly unlikely that in any real world task lasting less than one day there were really hundreds of distinct decisions that needed to be made by the user about appropriate actions to be taken by the agent/harness. It is also highly unlikely that the problem of decision fatigue seen here is somehow magically different to the same problem that countless UI designers had encountered and designed around in other systems long before harnesses running LLMs came along.
This is unfortunately the kind of result you get when you eliminate skilled and experienced people with real understanding of their field and replace them with repeated automatically-generated attempts to solve the same problem until something meeting some basic standard of correctness is found. It's as if the story of agentic AI as it exists today had been compressed into one perfect example of what it can do that is good but also why it's still fundamentally flawed.
I think we agree that there's an interface problem. But there's an intelligence-complete problem hiding underneath; which is why the first instinct was to recruit the human-in-the-loop in the first place. Turns out the human has one of those unintuitive failure modes that occurs when the system gets past a certain level of reliability.
Meanwhile, let's leave the hobby-horses in the closet for now. I won't comment on people's programming tool preferences.
This poor soul. There are few protocols I hate implementing more than WebRTC. Getting a simple client going means you need to quickly acclimate to SDP, TURN/STUN, ice-candidates, offers, peer-to-peer protocols, and the complex handshake that is implemented from scratch each time. I can't imagine re-writing the whole trenchcoat of protocols and unintended "best-practices".
The first time I was able to get a working webrtc datachannel setup with aiortc was when LLMs became a thing, before that it it was pretty much impossible full stop. Nobody knows what or how, there are no examples. It's a horrible protocol that just needs to die.
I'll take a contrarian view here. Disclaimer: I'm interpreting "safe" as in "usability". I've been driving Ubuntu for years for gaming purposes, and it's come a long way. Most drivers are installed out-of-the box. The apps I care about run just fine.
But.... Relative to MacOS Ubuntu is certainly not as user-friendly. It's worth noting that Linux distros will force you to confront the command line at some point. If you come from OS-es where the most technical thing you have to do is pop open settings to set screen-share permissions or "right-click -> open" to install a package, you'll notice a stark difference.
I recently tried to help my mom reset her Apple account password on a modern Mac. Absolutely and utterly shite process at almost every step. I couldn't believe it. Even had a screen show up completely blank that was obviously supposed to have something there but I have no idea what.
Finder is garbage from a power user UX perspective.
And the extra hoops to jump through to manage windows instead of applications is super annoying IMO.
I think Apple is slowly enshitifying it's UX advantages.
What the author touches on with before and after "declarative thinking" is largely applicable to all Directed Acyclic Graph (DAG) workflows, and not just signals. They are 100% correct that there is a mental shift. Yes, you can use magic to implicitly declare your DAGs with signals. You can also be really explicit with dependencies.
DAG-based workflows incur a cost in terms of complexity, but there are a few advantages to using DAGs instead of sequential.
1. Parallelism becomes inherently built-in
2. It's easier for a new developer to understand the direct dependencies of a node on other nodes (compared to sequential). Sometime in the future, a developer may want to split off a task or move it up/downstream of other tasks.
3. Fault tolerance & recovery becomes easier. Just because 1 step fails, doesn't mean that the whole workflow must come to a halt.
The Signals libraries I know of (including reaktiv) are throwing an exception if a dependency cycle is detected in the computation step. But that doesn‘t solve infinite executation loops completely because the user still can define an Effect that updates its (in)direct dependencies - that means User caution is still needed. Angular tried to prevent that in their older versions by not allowing to set other Signals in Effects. But they reverted that decision.
I have aphantasia, and today I learned that I also have SDAM.
There are benefits. For example, I find that I have no issue forgiving people. It's more work for me to harbor a grudge. I don't relive the burden of that initial pain of betrayal when someone close to me harms me, so it's easy to forgive and literally forget.
I also have aphantasia and I do believe I have SDAM, too. I also had a traumatic childhood and am a combat veteran. I think I've always been this way but that's a hard question for me to truly answer and is one that I grapple with a lot, actually.
> How about the pain of reliving old memories? I could do with a little less of that right now.
I don't relive the past the way it seems most people do. I know what it's like to feel hurt or feel stuck but I don't generally feel emotions about things in my past. That's good because I've endured a lot of bad shit but also sucks because my wedding day is kind of like any other day to me, as was the birth of our kids. I guess I know all of the good and all of the bad things that have happened to me -- though I don't really carry them with me the way some people seem to, they're part of me but I don't spend much if any time ever thinking about them -- but I don't feel any particular way about any of it. I know that I love my wife and kids more than life itself, I know these facts and I know the timelines but there's not much else there. I know these things but there's no emotional weight to them.
Me too. I’ve had some very traumatic experiences the last few years, and the emotional scars will never heal. I’m not the same person I was before, and I never will be.
Some people these days are hoping to combat aging and make potentially infinite life extension possible. I find that idea far more terrifying than death. Infinite lifetime would mean that experiences more emotionally and physically painful than I can even imagine would happen countless times. Slowly I would become so messed up by all the accumulated traumatic memories that I would no longer be able to function at all. I would only consent to an infinite or radically extended lifetime if I could also selectively erase memories I don’t want to keep.
I have many times thought about how scars and tattoos have a lot of similarities. From a certain perspective, a tattoo is simply a bit more intentional. A tattoo is like saying, "I belong to this group and it shows". I think of an emotional scar as a tattoo that is 100x bigger than a regular tattoo: it's so big, that you can't see it, it's like not being able to see an image when you zoom in too much. And, even though you might not see it with the naked eye, you can feel it, it's something on you that says "I was there", "I experienced that", "I used that to become the person I am".
And, then you might recognize that all of our personalities are constructed out of these scars, it's just that most of them we're not aware of and most of them aren't painful to think about. A time comes, when you notice that your association with a given negative memory becomes more neutral, there's a bit more distance between you and it.
I can say for myself that every experience I labeled as negative, I was haunted by, turned out to have a positive outcome at the end. There are hardships that "haunt" me now, and I don't know how it will have been a positive influence on me, but I believe that it will, and that helps.
I hope I don't come across as pushy with my viewpoints. I resonated deeply with what you said, and felt the need to share.
By the way, a practical tip, I find that if I prompt an LLM with something like:
> I'm going through [a difficult time]. Help me reflect. Ask a question or give me a prompt, I'll respond, and so on. Act like a friend.
That has been for me surprisingly effective for releasing debilitating emotional stress.
Sounds like functional forgiveness, as apposed to decision or emotional arc forgiveness. "Letting go" being a very strong default, that would require special maintenance to avoid doing.
I am this way in the long run. Regardless of the situation, at some point I just realize I completely don't care.
Once I know someone operates in a problematic way, I spend some time figuring out how they tick. People really do operate differently internally, and understanding the variety of cognitive damage that nature and nurture can inflict goes a long way to being able to be objective about people's shortcomings.
Then I use common sense to avoid any recurring problems, without negative feelings. I may not want to be connected with someone anymore, but if I run into them, or we are thrown together for some practical purpose, I can be amiable, without any conflicted feelings.
I think it's more about not remembering the feel of being hurt by someone - like he knows that this person did something bad to him but he doesnt't remember emotions connected to that event, that's why it's harder to hold a grudge.
What is it about React that you hate? React has been the near defacto framework for frontend development for a decade now [1]. Like it or not, it's not going away anytime soon.
As a Svelte / vanilla TS dev, I hate React because looking at it makes me feel like I’m drowning in obtuse, leaky abstractions, none of which feel necessary and all of which are required to do _anything_ at all.
Another react hater here. Here are some of my beefs.
* Components don't have exposed identities, but component state is based on identity. Secretly they're fibers.
* Everything is treated as if it's immutable. Reference equality is used to infer no changes. Working with array-based state, or almost anything really, is awkward and unnecessarily verbose. Spread all the things.
* The rules of hooks. These are just implementation constraints based on the rest of the design decisions of react.
* You can't use symbols as keys. This is small, but particularly irksome for me.
* The smallest unit of UI change is the component render function.
* Effect dependencies need to be listed explicitly.
> Everything is treated as if it's immutable [...]
Immutability is a great callout; frontend ecosystem is quite divisive on it.
For my flavor, as React exploded, redux and the advanced state management frameworks came and made everything bananas[1]. "It solves real problems for advanced apps"; maybe but I could never shake that these problems are self-inflicted.
There's a mathematical functional purity that's nerd-snipe worthy; but reactivity with mutation observers just seems to model the real world of UIs better.
Anyway, https://mobx.js.org/README.html is the exact opposite take: mutate your state! Subscribe to changes to your heart's content.
The divisiveness is real, it's what makes staying up to date exhausting.
[1] Come on, no one seriously thinks "bind action creators" made intuitive, ergonomic sense.
Mobx is cool. Nice to see some other mutation enjoyers. I also made my own thing[1] called "mutraction" (portmanteau of "mutate" and "tracking") based on this premise that uses jsx and mutation. I mostly made it prove that it could be made and to understand how it would work.
The Australian and the USA's immigration system are substantially different in terms of underlying values. The Australian system assigns points based on skill and merit. The US has an emphasis on reuniting families, a lottery system, and difficulty through ambiguity. Anecdotally, my friend who immigrated from Silicon Valley to Australia was able to explain his process to me in about an hour. In contrast, I have had the USA system explained to me many times, and it still hasn't clicked. I can't help but to feel like this is by design.
As for our (USA's) housing crisis, the New York Times had a podcast about that just four days ago [1]. There are some notable parallels to what you have described. TL;DR: The 2008 recession pushed us from building 2.2 million houses a year to 600K, for the last 20ish years. The skilled laborers and tradesmen who used to build houses have closed shop. Now here we are years later and millions of houses short with no clear way to reboot the industry.
There's substantially more immigration to Australia through university scams (fronts that don't actually educate) than genuine immigrants. The majority is not skill and merit based because of the "temporary" "students" who can work and never leave the country, as well as the chain migration loopholes.
Australia has almost the highest immigration per capita in the world, and a massive chunk of that is pure fraud. [1]
75% of "students" come in via unregulated agents, many of whom direct students to these university fronts.
In fact, Australians overwhelmingly reject mass immigration. 71% oppose it and are regularly ignored by the powers that be on both sides. The left imports immigrants for ideological reasons and the right imports them for cheap labor for their corporate buddies.
While Australia might have a lot of fraudulent immigration, they harass the normal tourists under the pretense of preventing fraudulent immigration.
This happened some years ago, so perhaps the system has been improved meanwhile, but I strongly doubt it.
At that time, I was living in an European country, but I was working for a subsidiary of an Australian company. There was a reciprocal agreement with Australia that visas must not be required for visiting the other country.
In Europe, the agreement was observed, so any of our Australian colleagues could visit the local subsidiary at any time, no questions asked.
However, there was a moment when the Australian headquarters decided that a team from the European subsidiary must come in a visit to them, for an important meeting where some future strategies had to be decided.
We expected that the travel to Australia would be as easy as the reverse travel for the Australians, but no, while Australia could not demand a visa, which would have been illegal, they had replaced the visa requirement with a requirement for some kind of "electronic" permit, whose name I do not remember, which was nothing else but a visa with another name, because without it you would have been denied entry in Australia.
To obtain the Australian permit one had to provide a really ridiculous amount of personal information about yourself and about a lot of family relatives (not only spouse, parents and siblings, but even grandparents), certainly at least as much as when applying for some security clearance of the highest level. I have traveled through many countries, and even those that require visas do not request such an amount of information. You do not need to provide such information even when going to Israel, where they have reasons to be more careful.
The most annoying was that they were not satisfied with providing a bank account where you held an amount of money greater than would be required for all your travel and stay in Australia. They also required for that bank account a detailed lists with all the transactions done with that bank account for the past three months.
Initially we have provided the list of banking transactions with only the amounts of money that had been transferred, but that was not good enough, they wanted for each transaction the complete information, like the invoice that has been paid and for whom. I could understand if they had required only the source of the money that credited the account, to determine who was paying for the travel to Australia, but a complete list of transactions, including everything that you have bought, was an abusive request.
If we had known in advance the Australian system, we would have created three months earlier a bank account with the only purpose of storing money for the Australian visit, which would have had an empty list of transactions. As it was, because this was a business trip, the account with money for the trip was the company account. Disclosing all the transactions from the company account could potentially disclose some confidential information for competitors and it would also disclose to the employees going in that trip information considered confidential by the company, i.e. the salaries of all employees.
Due to the complications created by the need to provide all the information requested by the Australian authorities, the process for completing the applications for the permit was very long. Even after providing all the required information, on-line to some immigration offices located in Tasmania, the processing of the applications took a few months. Because it was delayed so much, eventually the Australian headquarters has cancelled the visit to Australia and they have organized a meeting in Europe, where they did not fear that the Australians are illegal immigrants.
Our case was certainly not a singular one, because at the same time there was in the news a case when there had been an important meeting of some international organization, which happened to be organized in that year in Australia, and the representatives of some countries could not reach the meeting because they had received Australian visas much too late, even if they had been requested early enough and there was no doubt that they had a valid reason to come to Australia.
