Potential reduction in confirmations

[AlexW68]

Had a good go at Late, love it, nice work, it works the way I do, I like that it keeps you in the loop and it's quick.

A thought, having seen the -i-promise-i-have-backups-and-will-not-file-issues hahaha.

It would be nice to have a more granular approach to this, personally if something is being created from scratch just do it, if it's modifing existing code, then maybe I want to get involved in that.

Maybe a rules files per project dictating when to ask for confirmation and when not to?

Just a thought.

Thanks for Late.

[giveen]

I was honestly brainstorming some "whitelist"rules yesterday. Things that a person could add that would always allow certain commands.

[AlexW68]

allowing a global and per project list would work for me.

[mlhher]

This is definitely on the roadmap. It needs some genuine thought though as I do not want to see it implemented in potentially dangerous ways.

Maybe this discussion can be used as a braindump.

A whitelist is a strong concept and accelerating the velocity is always good but I'd rather prompt ten times too much than one time causing a (potentially catastrophic) issue. After all we are "just" parsing and comparing we are not using a real AST based parser.

Please keep in mind that in any case Security and Safety trumps Velocity.

[AlexW68]

Security and Safety is key,

maybe go both ways

Whitelist and blacklist e.g.

Blacklist = -

Whitelist = +

so

+createfolder
+createfile

-modifyfile

so always create folders and files if needed but always prompt for modifying files, starting with a default file that has all the different options set to prompt e.g. all - 's

just an idea.

[mlhher]

The issue is not necessarily the lists. At its core Late already uses a whitelist of bash commands.

Bash (and Pwsh) are both Turing complete which means you can do funky stuff.
If you have cat likely it should be allowed. What if it is cat >? What if it is cat &&? Manually parsing these without actually compiling the AST is a rabbit hole. For example if you want to autoexecute cat even if it has compounded commands you should be able to check what the compounded commands are. That is not reliably possible without AST parsing. Another issue is a command like find. Find is absolutely destructive since you can pass it a callback to every file.

[giveen]

I'll think about it.

Mainly i would use https://gtfobins.org/ as ideas where simple linux commands can be abused so I want to ensure that nefarious versions of commands can't be called.

But like previously stated, if a user wants to screw their system, and YOLO it by adding all commands here on their own, who are we to say no? I like the idea of creating the function and the people can tune it to their liking.

[mlhher]

I do see your line of thought though I must disagree.

We cannot have an infinite list of commands backed up that is simply unmaintainable (especially when moving towards Windows).
And specifically the bigger issue I see especially compared to the yolo flag: The yolo flag explicitly says "hey this is unsupported, please do not ever use this, if you use this it is your own fault". I am heavily worried that a configurable list gives a false sense of security specifically seeing some of the latest issues users have had.

The main issue here is we simply cannot rely on a blocklist while we are doing strings parsing. That is specifically why you are prompted for anything that we cannot parse.

[AlexW68]

Maybe a just a whitelist personally happy for new files/folders to be created, where I want confirmations is destructive stuff, modify, delete etc.

Absolutely anything that cannot be parsed/understood prompt for confirmation.

Just creating new files/folders for me would reduce confirmations significantly, mainly because my workflow is I use AI to generate the basic files, I take over from there and modify manually, of course my workflow maybe very different from the norm.

[giveen]

For me, using 'cat' and 'echo' are easily things that could be allowed. However 'find' can be used to write .

[giveen]

Building on AlexW68's last point , I think narrowing the ask to new file/folder creation only is actually the right approach, and here's why it sidesteps the AST parsing problem entirely:

Instead of trying to parse what a shell command might do, we look at the outcome: does the target path already exist?

• If the path does not exist → creation only, nothing is being overwritten or deleted → auto-approve
• If the path exists → modification or deletion risk → prompt as normal

This avoids the cat >, find -exec, compound-command rabbit hole completely because we're not analyzing the command at all , we're checking filesystem state before execution.

The second constraint I'd add: scope it strictly to the project's working directory. If the target path falls outside the cwd of the current session, it prompts regardless. That keeps the blast radius contained , the agent can only auto-create within the project it was launched in, not anywhere else on the filesystem.

So the rule set would be very small and conservative:

Condition	Action
Target path does not exist and is within cwd	Auto-approve
Target path already exists	Prompt
Target path is outside cwd	Prompt
Anything unparseable or ambiguous	Prompt

This lines up with AlexW68's workflow (generate scaffolding, then take over manually) and doesn't require maintaining a command list at all. It also avoids the false-sense-of-security problem since the rules are based on observable filesystem state, not command pattern matching.

[giveen]

## Code sketch: auto-approve new-path creation within project root

### How it works

Instead of parsing what a command *might* do, we check two observable facts before execution:

1. Does the target path already exist?
2. Is the target path inside the project's `cwd`?

If both answers are no/yes respectively, and the command is the simplest possible form (one verb, one argument, no flags or chaining), we auto-approve. Anything ambiguous falls through to the existing confirmation prompt unchanged.

---

### Files changed

| File | Change |
|---|---|
| `internal/tool/permissions.go` | Add `isNewPath()` helper |
| `internal/tool/implementations.go` | Add `extractTargetPath()` helper + update `ShellTool.RequiresConfirmation` |

---

### `internal/tool/permissions.go` — new helper

```go
// isNewPath returns true when the resolved target path does not yet exist
// AND falls within the current working directory.
// Both conditions must hold — creation outside the project root always prompts.
func isNewPath(path string) bool {
    if !IsSafePath(path) {
        return false // outside cwd — always prompt
    }
    _, err := os.Stat(path)
    return os.IsNotExist(err) // true only if path is genuinely absent
}
```

### `internal/tool/implementations.go` — new helper

```go
// extractTargetPath returns the target path argument for simple creation
// commands (mkdir, touch, New-Item). Returns "" for anything compound or
// ambiguous so the caller falls through to the prompt path.
func extractTargetPath(command string) string {
    fields := strings.Fields(strings.TrimSpace(command))
    if len(fields) != 2 {
        return "" // compound, flagged, or no-arg — don't try to parse
    }
    switch strings.ToLower(fields[0]) {
    case "mkdir", "touch", "new-item": // new-item covers PowerShell
        return fields[1]
    }
    return ""
}
```

### `internal/tool/implementations.go` — updated `RequiresConfirmation`

The new check slots in after the metacharacter guard and before the existing whitelist logic. Everything else is unchanged.

```go
func (t ShellTool) RequiresConfirmation(args json.RawMessage) bool {
    var params struct {
        Command string `json:"command"`
        Cwd     string `json:"cwd"`
    }
    if err := json.Unmarshal(args, &params); err != nil {
        return true
    }

    if runtime.GOOS == "windows" {
        return true
    }

    if containsShellMetacharacters(params.Command) {
        return true
    }

    // Auto-approve only if the target is a new path strictly inside cwd.
    // extractTargetPath returns "" for anything compound or flagged,
    // so ambiguous commands always fall through to prompt.
    if target := extractTargetPath(params.Command); target != "" && isNewPath(target) {
        return false
    }

    // Existing whitelist check — unchanged.
    baseCommands := getAllBaseCommands(params.Command)
    for _, cmd := range baseCommands {
        if !whitelistedCommands[cmd] {
            return true
        }
    }
    return false
}
```

---

### Decision table

| Command | Result |
|---|---|
| `mkdir src/components` (path doesn't exist, inside cwd) | ✅ Auto-approve |
| `mkdir src/components` (path already exists) | 🔒 Prompt |
| `mkdir /etc/newdir` (outside cwd) | 🔒 Prompt |
| `mkdir -p src/a/b/c` (has flags) | 🔒 Prompt |
| `mkdir src && cd src` (compound) | 🔒 Prompt |
| `touch src/index.go` (file doesn't exist, inside cwd) | ✅ Auto-approve |
| `find . -name foo` | 🔒 Prompt |
| Anything unparseable | 🔒 Prompt |

---

### What this does NOT change

- Windows behavior is untouched — always prompts regardless
- The existing bash whitelist is untouched
- The metacharacter guard runs first — compounds never reach this logic
- `IsSafePath` is reused as-is, no duplication

[mlhher]

The idea sounds compelling. I will take a look at it.

[danielfdickinson]

It does seem worth a thorough looking into. It'd be handy to have less confirmations, but I like the security first model.

[merbanan]

The current logic in a debug loop is tiring to the point of not usable, I get asked every time when rebuilding . In the issue #32 I basically suggested a white list. I still believe in some kind of whitelisting but maybe it only should be some kind of curated list for a handful of common actions? And that the model is steered to use those actions.

[mlhher]

I have already explained why I will not go forward with "simple" lists.
If anyone volunteers to write both a bash and a Powershell AST parser I will gladly and happily implement the list format.

[diagonalfish]

Is there a reason to prefer a shell/bash tool for the agent over giving it more 'safe' tools implemented in Go? Does the extra context degrade things too much? I was experimenting with giving it a find, grep, etc. tool to use last night (and then taking away bash) and it seems to work, but I'm still learning how agent harnesses/tool calling behavior works so this is a genuine question!

[mlhher]

If you look at the git history you will see that I actually removed multiple native tools (grep is the immediate one). I am not sure about other models but specifically Qwen (and also Gemini) have a weird tendency where they feel like they "must" use bash over anything. I am pretty sure this is a training artifact. In that case we should just support the model.

I can look into putting it in again though at least for Qwen3.5 it still seemed to "violently" prefer using bash grep over the native tool grep.

[diagonalfish]

Yeah, if Bash is available (or even mentioned in the system prompt) Qwen3.5/3.6 aggressively prefers it, for sure. I could get subagents to consistently use other tools if I take Bash away entirely, though sometimes they still get hung up if they're determined to do something and can't figure out how to do it without shell commands.

A happy medium might be to give it a handful of safe tools along with shell but aggressively limit what it can do with the shell commands, giving it fail messages that nudge it toward available tools. Would require some experimentation though. Right now, I've given my little personal branch these tools, after consulting with it about what tools it thought would be handy:

• find (uses filepath.Walk to provide glob file/directory listing, it lets the agent specify files or directories if it wants)
• grep (self explanatory)
• file_op (allows creating, deleting, and moving files - requires approval for deleting)
• dir_op (allows creating and deleting directories - approval for deleting)

All of them restrict the agents to the project directory using IsSafePath() and they seem to work pretty well.

But... every tool costs context space, so it's a tradeoff. For things like git, go and other language-specific tooling, etc, I'm not sure what the best approach is. Skills? Something else?

[giveen]

https://github.com/vaaraio/vaara

An engine designed to audit tool calls.

I started doing similar work inside my infosec tools I've build that have an audit and risk setup.

[mlhher]

"Zero runtime dependencies for the default install." lol
I took a bit of a look at it while it seems really interesting I think the main issue is that it also relies on a probabilistic guess. I really want to avoid having guesswork regardless how accurate it might be.

I am open to being argued but it will take a bit it just seems too irresponsible considering all users.

[giveen]

Test code for "tool calls"

Update Summary: New-Path Auto-Approval + Comparison Test

What we changed

• Implemented conservative auto-approval for simple new-path creation commands within project scope.
• Added support for these simple forms only:
  • mkdir
  • touch
  • new-item

Decision rules now

• Auto-approve when:
  • Target path does not exist
  • Target path is inside project root
  • Target path is inside the active session cwd
  • Command is simple/unambiguous (single verb + single path, no flags/chaining)
• Prompt when:
  • Path already exists
  • Path is outside cwd
  • Path is outside project root
  • Command is flagged/compound/unparseable/ambiguous
  • Windows (unchanged: always prompt)

Key implementation points

• Added path-state helper:
  • internal/tool/permissions.go
• Added command target extraction + RequiresConfirmation integration:
  • internal/tool/implementations.go

Unit tests added/updated

• Target extraction tests
• New-path vs existing-path behavior
• Outside-cwd behavior
• Ambiguous/flagged command behavior
• Before-vs-after comparison test for the same scaffold task:
  • Old logic prompted 3 times
  • New logic prompts 0 times

Files with test updates

• internal/tool/implementations_bash_test.go
• internal/tool/implementations_test.go

Validation

• Ran: go test ./internal/tool
• Result: passing

[giveen]

@AlexW68 please try the latest build and see if it helps

[aa956]

One more angle to think about: filesystem corruption may not the worst problem - data exfiltration may be.

I'm running late in rootless podman container so they may nuke the container, just make clean && make build on desktop and there's a new fresh container ready in seconds.

But what about API keys, access tokens, secrets in environment variables, GPG or SSH keys accessible to agents?

By the way, will post separate discussion with my current podman setup if someone wants to run with -i-promise-i-have-... slightly more safely.

[mlhher]

But what about API keys, access tokens, secrets in environment variables, GPG or SSH keys accessible to agents?

Laughs in OpenClaw.

The PR for the bash AST parser is open and if @giveen reports things seeming fine as before on Windows too I will likely merge it. This should solve most issues for now. The default allowed commands should not be able to do any harm. If a user explicitly (always) allows a command it becomes their own responsibility (always allow is also inside the PR). Further protection is that Always Allow does actually check the passed flags and only allows the exact specific one while taking into account e.g. numeric flags. If you always allow git log --online -1, git log --oneline -10 will also be allowed. git log --output will still require a permission.

I think the container approach is by far the safest as you noted yourself. Could potentially integrate it though would require a re-evaluation. I think going with the ast parser for now is the best middle ground.