Project Settings, Permissions, and Team Sharing

# Transcript — ai-coding-setup ep 04 _Auto-generated with mlx-whisper (mlx-community/whisper-base.en-mlx). Lightly readable; not edited._ You clone a new repo, you open up your AI coding assistant, you're feeling productive. Oh yeah, fresh code base ready to go. Right. So you ask it to run the dev server and instantly you get a prompt, approve running this command. And you just click yes because, you know, exactly. But then it asks, approve, get status. Yes. Read a file. Yes. Run the type check. Yes. It just keeps going. It really does like 40 approval prompts into your very first session and your flow is just entirely shattered. Completely broken. You just end up killing the terminal process. Right. You turn the AI off and just go back to your old workflow, doing it manually, which completely defeats the entire premise of having an autonomous agent in the first place, you know, it really does. And that is exactly the painfully familiar picture we are unpacking today because we build these tools to act as force multipliers, right? There's also offload the cognitive burden. Not add to it. Exactly. When the agent becomes this like bottleneck that requires your explicit written permission for basic REPL operations, the read evil print loop stuff. Right. The basic REPL stuff, it devolves from an assistant into basically a micromanagement simulator. A micromanagement simulator. That is a perfect way to put it. I mean, evaluating 40 granular execution requests takes more mental energy than just typing the commands yourself. So true. But here's the thing we want to establish right out of the gate for this deep dive. The AI tool itself. It is not actually the problem. No, not at all. Yeah. Language model is fine. Right. The tool is functioning exactly as designed under a zero trust model. The actual problem is the absence of configuration or just, you know, fundamentally misunderstanding how that configuration is supposed to be structured. Exactly. So today's deep dive is strictly for working software developers who are looking to optimize their environment. No hype today. Just practical under the hood mechanics. Yeah. Little dry, maybe, but essential. We are looking at exactly what your team should share, what needs to stay strictly personal and how to configure your setup to stop the endless permission prompts. Without compromising security, which is the really tricky balance to strike. Right. Because nobody wants to be the developer who accidentally lets an agent nuke the production database. Yeah, that's a bad Tuesday for sure. So to start, let's break down the actual architecture of these configurations because it's not just one big settings file, is it? No, it's actually a strict three peer architecture. It resolves permissions from three specific files in a hierarchy. And those tiers are global project and local. Right. And understanding how the AI resolves those three tiers is like critical to fixing the prompt fatigue. Okay. So let's use an analogy here for the web developers listening. Is it kind of like CSS cascading rules? Yeah, that's actually a really solid mental model or even how deployment environments resolve environment variables. Okay. So how does that map to the AI configuration? Well, the global file sets your baseline system wide defaults. It's like the browser's default style sheet. Right. The stuff that applies everywhere, no matter what. Exactly. Then the project file sets the specific rules for the team repository. That's your main CSS file. And then the local file. That applies your personal overrides on top of everything else, like an in-line style that trumps the rest. Got it. So let's look at each of these by their actual intent, starting with the global file. Where does this live? So the global file lives on your machine only, typically in your home directory. It never, ever goes into version control. Because it's just for you. Right. It contains your cross project defaults, tools that you trust unconditionally across any code base you touch. Okay. But if I just configure everything globally, so I never get prompted, does that solve the problem for my team? No, not at all. Yeah. And that's a huge trap. It's a massive anti-pattern because it's entirely selfish, you know, selfish how because it solves the prompt fatigue for your machine. But the moment a new hire clones the repo, they're back to getting hit with 40 prompts. Oh, right. Because they don't have your global file. Exactly. Which is why we have to talk about the middle layer, the project file, the team consensus layer. Right. This file is committed to version control. It sits in the repository, usually in a hidden directory. And it's shared with the entire team. So this is where we actually fix the onboarding problem. Precisely. It contains the tools and commands that everyone agrees are safe to run without approval, specifically within the boundaries of this one repository. Okay. But what if the team agrees on something, but I personally need to tweak it. Do I edit the shared project file? No, you don't want to pollute the shared file with your personal setup. That's what the third tier is for the local file. And where does that one live? It sits right next to the project file and the repo. But and this is crucial. It has kept strictly out of version control. It gets get ignored. Always. It is strictly personal. It's used for your local binary paths, individual model preferences, API keys, that sort of thing. Okay. So let's talk about the resolution rules, the cascade. If I deny something globally, but allow it in the project file, what happens? The AI applies the most specific rule. The cascade resolves as local, then project, then global. So the closer it is to the specific context, the more weight it has. Exactly. So if you have a strict deny by default posture for network requests in your global file, which is a great idea, by the way, highly recommend that. But your specific repo relies on a local dev server that needs to poll a network you just explicitly allow that polling in the shared project file. And the agent will see that project rule and override your global denial just for that repo. Right. And if there's a permission missing from the project file entirely, like the team didn't think to add it. I'm guessing I can just add it to my local file without messing up my teammates setups. You nailed it. You get to preserve your autonomy without forcing your workflow on everyone else. I love that. So to stop the prompt fatigue for everyone at once, we have to really focus on that middle layer, the shared project file. Yeah. Adding a committed project settings file is arguably the highest leverage. Five minutes a team can spend on their AI tooling. Five minutes to solve the onboarding nightmare. I'll take that trade. It entirely solves it. But people get tripped up on what actually belongs in this shared allow list. Well, let's break that down. And let's focus on the intent of the commands rather than reading out exact JSON syntax, because nobody wants to hear us read brackets on a deep dive. Good call. So the most foundational intent is granting blanket permission to read any file. Wait, blanket permission, just any file in the repo, any file in the bounded directory of the project. Yes. I know a lot of security conscious developers who hear blanket read access and their alarms start blaring. Sure. It sounds scary, but you have to understand how these agents work. The agent reading code is almost never a security concern because it's not changing anything. Right. And more importantly, an AI coding assistant doesn't just intrinsically know your code base when you open it. It has to build context. Exactly. It relies entirely on rag retrieval, augmented generation and AST parsing to pull relevant text chunks into its context window. So if you restrict its ability to read files, you're essentially blindfolding it. You are. If you tell it to implement a new feature, it needs to traverse your project, look up interfaces, check schema files. And if a human has to click approve every time it wants to read a different TypeScript interface, the tool is useless, completely paralyzed. Read or only file system access is universally safe to automate in the shared config. Okay. So reading is safe. What about executing things? Because that's where the real fear comes in. Well, the next category you must allow is package manager scripts, like running tests or type checks. Exactly. NPM run test, cargo check, spinning up the dev server. These are safe because they are standardized verification tools. Right. The team has already agreed on these scripts. They're in the package.json or the make file. Yeah. When the agent writes code, it needs to run the linter and the unit test to make sure it didn't break anything. And forcing a human to approve a test run is just turning the developer into a human macro. It really is. You want the agent to iterate, test and refine its code entirely in the background before it bothers you with the final result. Okay. Makes sense. What about version control? Get commands. You should unconditionally permit read only get commands. Like checking logs or diffs. Yeah. Get log, get diff, get status, get branch. The agent needs to understand the historical context and the current state of the working tree. And since those commands don't mutate the repository state, they're safe. Exactly. Blocking get status behind a prompt just actively hinders the agent's navigation. There's another thing the source material highlighted for this file. Basic file system reads and printing to standard output. Ah, yes. The standard output is crucial. It's essentially echolocation for the agent. Echolocation. That's an interesting way to put it. Can you expand on that? Sure. Unlike you or me who look at a graphical UI, the agent relies entirely on piping text streams back into its context window. So when it runs a command, it's blind until it reads the output. Right. It intercepts the stud out in stutter buffers. It runs the law, captures the text that comes back and parses that to understand the directory structure. It pings the terminal and uses the returning echo to see. Exactly. So if you require human approval before the agent can pipe a command's output back to its own internal processing loop, you break the fundamental read evil print loop. You completely break it. Allowing standard output processing is non negotiable. Okay. So we've got read access, package scripts, read only get and standard output. There was one more specific detail from the source for team consistency, setting the AI model tier in the shared file. Right. Why is that important to put in the project file instead of just letting everyone choose their own? Because if you leave the model choice, unconfigured, you end up with fragmented baselines across the team. Give me an example of how that plays out. We'll say you have one developer using an extremely capable, but very heavy model. It can refactor complex logic effortlessly. Okay. But another developer on the same team is defaulting to a lighter, faster model that maybe struggles with that same task and introduces subtle bugs. So they're getting completely different results from the exact same tool. Exactly. By defining the baseline model in the project file, you ensure the whole team defaults to the same cognitive standard. It makes debugging much easier when teammates are comparing their AI outputs. Huge time saver. I am going to push back on this entire philosophy for a second, though. Okay. Let's hear it. If reading my code isn't a security concern and the AI is generally trustworthy to run tests and pull Git status, yeah. Why not just allow it to do whatever it wants? Like why meticulously list out allowed commands? If I'm working in a disposable Docker container, why not just granite wildcard permission, let it execute me? Uh, the wildcard. All right. Because if it breaks something in a container, I just rebuild it in 10 seconds, wouldn't a wildcard be the fastest way to eliminate prompts? That is the most dangerous shortcut developers take. The source specifically calls this out as the broad permission trap. Okay. Explain why it's a trap if the environment is disposable because you're assuming the only risk is data loss. I'll just nuke the container. Who cares? Yeah. That's the standard argument. But data loss isn't the primary risk mechanically. We have to consider context window poisoning and token efficiency. Context window poisoning. How does that happen from a shell command? Well, the AI model is trustworthy, but it's not infallible. It's a text prediction engine, not a deterministic state machine, meaning it hallucinates. It hallucinates. It misreads your intent. It misunderstands command line flags. Okay. So say it hallucinates a command. Let's say it's trying to clean up a build directory. But instead of targeting dot an artist, it hallucinates the path and recursively deletes a massive system directory inside the container. Okay. The container is ruined. I still just rebuild it. But wait, consider what happens in the seconds before you rebuild it. The agent executes that destructive wildcard command rights. The shell starts throwing hundreds, maybe thousands of lines of permission, denied errors, missing file warnings, massive stack traces. And because it has wildcard permission, it intercepts all of that strata output and pipes it directly back into its context window. It tries to read its own massive error log. Yes. It consumes thousands, maybe tens of thousands of tokens ingesting garbage error logs from a hallucinated command, which costs actual money. It burns through your token budget instantly. And worse, it then tries to reason about those errors, generating more commands to fix the message just made spiraling into a costly automated failure loop. Exactly. You aren't just breaking in a femoral environment. You are financially and mechanically crashing the agent's logic loop. That is wild. I never thought about the token cost of a hallucinated shell error. So the prompt. It isn't just protecting the file system. No, it's acting as a literal circuit breaker. A manual prompt forces the system to pause before executing high consequence actions. It asks the human to verify the semantic intent of the command against the syntactic reality of the shell script. Like when an agent aggressively appends an all flag to something. Right. The human developer have the context to recognize that danger. The agent usually doesn't until it's too late. So we need a solid rule of thumb for what actually requires this circuit breaker. What's the rubric? It's pretty straightforward. First, read only operations are safe to allow automatically. We cover that. Yep. Reads are safe. Second, writes to the file system, specifically via arbitrary shell commands those require review. You want to see the script before it mutates your files. Makes sense. And third, irreversible operations must always trigger a prompt. No exceptions. We're talking about things like force resetting version control. Get reset hard, removing files, get push force. High consequence mutations must never be in the automated allow list. What about external network interaction? Say it wants to curl a script from the web. Never. Anything touching external services or relying on credentials should never be in the shared file, which brings up a really important question. If we are deliberately keeping credentials and personal preferences out of the shared team file, where do they go? Yeah, where do they actually belong to ensure they don't leak to the rest of the team? That leads us directly to the local tier, the personal overrides. And there is a massive trap here that the source material is very aggressive about. The getting nor rule. Yes. The very first step before you even type a single line of JSON into your local settings file is ensuring that local file is added to the project's ignore list. It has to be in the dot getting nor if it isn't, someone on your team will eventually commit an API key to the main branch. It's inevitable. OK, but let me push on the reality of modern dev environments for a second. Most enterprise repos today use pre commit hooks, right? We have tools like truffle hog or GitHub advanced security. Yeah, secret scanners. Right. They scan the code and rejects match for hard coded secrets before the commit is ever allowed to push. Aren't we already protected against leaking API keys even if the file isn't ignored in a traditional human only workflow? Yes, those pre commit hooks are great. But injecting an AI agent introduces a radically different attack surface. Oh, so it's called context window leakage. OK, break that down for me. How does an AI bypass a pre commit hook? Because a pre commit hook only scans files that are staged for version control. It monitors the Git index. But think about how the agent operates. If you leave an unacknowered local file lying around with a database password in it, the agent might just read that file. Exactly. It reads it simply to understand its own configuration parameters. It pulls the raw string, your actual password into its active memory into the context window. Yes. And once that key is in the context window, it is no longer just sitting safely on your hard drive. It's being transmitted. It is actively being sent over the network to the models API provider. Anthropic open AI, whoever. Oh, wow. The secret could be inadvertently logged in a crash report or echoed back into standard output or captured in the provider's telemetry. And the pre commit hook is a completely blind to all of that because the file was never technically staged. Exactly. The only way to secure local credentials is an air gap. You have to structurally isolate them from shared execution context via the dot shitting or file. That makes the ignore rule significantly more critical than just avoiding a messy commit history. It really is a zero tolerance policy. OK. So once that air gap is established, we can safely populate this local file. Give me some examples of what actually belongs in here, focusing on developer intent. A great example is personal tooling. Say a developer prefers using the GitHub CLI, the GA command. Yeah, it's a great tool. It is. You might want the agent to use it to query open issues or read PR comments directly from the terminal. But if I put authorization for the GACLI into the shared project file, then you are effectively mandating that every engineer on your team must install and authenticate that CLI on their machine just to avoid an error when the agent runs, which violates the whole principle of the shared baseline. Exactly. Some teammates might prefer the way of UI. So personal binary dependencies like G belong strictly in your local file. What about opening files like editor integrations? Same principle. If you want the agent to pipe a diff into VS code or open a trace file in the new VIM, you can figure that locally because my choice of text editor is irrelevant to the repos logic. Right. Providing the local binary pass to neo-vim ensures the agent integrates with your workflow without polluting the teams config. Earlier we talked about setting the team's default AI model in the shared file. How does the local file handle model preferences? You can actually prefer a completely different model to your locally. Really. Even if the team said a default. Yeah. The team might default to a really fast lightweight model for routine stuff, but say you get assigned to untangle some massive undocumented legacy module. A total nightmare ticket. Exactly. For that, you might need maximum reasoning capability. You can use your local file to point your agent to the heaviest smartest model available while the rest of the team keeps using the fast one. Yep. You get surgical precision over the tools computational power isolated strictly to your machine. Okay. I have a question about the very first tier we mentioned. The global file. If the local file handles all these personal repo overrides, what actually goes in the global file? The global file is strictly for read only patterns that you want allowed unconditionally forever across every single project you ever touch. Oh, like global aliases or something. Right. General system utilities. The thing to remember is project specific commands defeat its purpose. If it only applies to your work repo, it doesn't belong in global. Got it. Okay. So we've covered the three tiers properly separated global project local. What does this actually look like in practice? You mean the actual workflow? Yeah, for a new hire on their first day, because the source material talked about hook integration. This is where it gets really cool. You don't actually need separate files for your configuration and your workflow triggers. They can be the same thing. Yeah. A single shared file can hold both the allow list permissions and session start hooks. Okay. Walk me through the exact sequence. We've got our configuration perfect. What happens when the developer clones the repo? Okay. So step one developer clones the repository. Step two, they open the terminal and start a session with the AI tool. And this time no 40 prompts. Zero prompts, because step three, a session start hook fires automatically. It runs get branch and get status to get context and prints it silently. Because read only version control is in the shared allow list. Exactly. Then step four, the AI notices missing modules and runs NPM install to grab dependencies. Also approved automatically because of the package manager rule. Right. Step five, it reads a dozen schema files and runs the type checker to verify the environment. All approved automatically blanket read access and verification scripts. Exactly. The agent is just zooming through the setup. Then step six, the developer asks it to commit the setup and push the code to the remote repository. It tries to run get push. And boom, it stops. The terminal throws exactly one prompt asking for human approval. Exactly as it should. Yes. That is the aha moment. Zero permission prompts for the routine, easily reversible busy work. And exactly one prompt for the action that actually deserves human attention. Because pushing to remote mutates shared state, that requires a human circuit breaker. That is the balance that makes an AI tool genuinely useful instead of just annoying. When you aren't numbed by prompt fatigue, you actually pay attention when the tool finally asks you for permission. You actually read the command before you hit enter. Exactly. Okay. This has been an incredibly practical deep dive. Let's briefly recap the core philosophy for everyone listening. Sure. It's all about that three tier architecture. Use a shared project file for read only team defaults. Use a hidden, get ignored local file for your personal overrides and credentials. And leave the prompts turned on for destructive actions. No wildcards. No wildcards. So here is your try this tomorrow takeaway. One concrete action you can do before your very next coding session. Oh, this is a good one. First, check your repositories, ignore file, make absolutely sure your local AI settings file, whatever the syntax is for your specific tool is listed in that. Dot, ignore, air gap, the context window. Exactly. Then spend just five minutes creating a shared project settings file, commit it to the repo, have it automatically allow read only version control and basic file system commands. Your team will thank you. The onboarding friction reduction is immediate. It really is. Now, to wrap up, there is a broader provocative thought extending from the source material that we want to leave you with. Yeah, because we've been talking about these concepts of global shared and local permissions, but they aren't strictly isolated to just one CLI tool. Right. The AI landscape is huge right now. It is. Think about how your current configuration philosophy maps to other AI assistance, like cursor or co-pilot or Ader, especially across different operating system. Oh, absolutely. How Windows handles binary pads versus a PO six system like Mac OS or Linux. It drastically complicates shared configurations. So the question Malover is, as your AI stack evolves, how do you map these permission tiers across multiple tools without creating a giant mess of configuration debt? Because the tools will change, but the need for layered security boundaries won't. Exactly. It's something every working dev needs to figure out. Yep. Get the architecture right now so you aren't fighting your tools later. Well said. Thanks for joining us on this deep dive. Go check those, get ignore files and we'll catch you next time.