Problems executing some variants of find

[aa956]

Not sure if the problem is in model, llama-server, late or that session being run on WSL but I've seen a lot of empty results returned to the orchestrator model when it run the following type of find:

find /full/project/path -type f \( -name \"*.c\" -o -name \"*.h\" \) | head -n 20

Looks like model tries multiple times until it gets to run it without double quotes, this succeeds:

find /full/project/path -type f \( -name *.c -o -name *.h \) | head -n 20

May it be some kind of over-escaping escape characters somewhere? Like if we try to run this in terminal this will return empty result:

find /full/project/path -type f \( -name \\\"*.c\\\" -o -name \\\"*.h\\\" \) | head -n 20

[mlhher]

From what I am seeing this might be a bug in Late. I am investigating.

[mlhher]

Might not be caused by us. We take the raw string we receive and pass it without transformations back to bash -c. Probably best to check if this is caused by your setup with WSL.

[aa956]

Thank you for the update, will investigate my setup.

[danielfdickinson]

FYI I have experienced a similar issue I have not had time to write up, yet. I am on Debian 13 (Trixie) using ollama. I see 400 errors from certain operations from ollama when using the gemma4 model due to invalid JSON (which when looking at the JSON is due to bad escaping when dealing with comments or shebang lines (beginning with '#')). The qwen3.6 model does not have the same problems though it requires a system prompt to tell it to use the current working directory instead of /home/testbed or /home/tb as the base directory for relative operations.

[aa956]

Not tried gemma myself yet with late, but have you added --gemma-thinking flag?

See https://github.com/mlhher/late/blob/main/docs/quickstart.md#common-flags

[mlhher]

As @aa956 noted when using Gemma 4 please use the --gemma-thinking flag. It injects the thinking token for gemma models. Thinking without them seemed unreliable during my testing (it might have changed).

Generally I had similar experiences with Gemma though which is why I switched back to Qwen.

I am not sure what you mean with your last sentence. Late injects the current working directory into the models context. If you want Late to work on a specific path, simply start the binary inside that path. Also refer to the Quickstart Guide.

[danielfdickinson]

I was using --gemma-thinking - it seems the issue is model-specific so probably not a late issue, but it in case it might have been relevant, I piped up.

For the last sentence: I found even if I was in specific path and requesting relative paths that there were what appear to be 'training artifacts' which result in qwen3.6 using /home/tb (and qwen3.5 /home/testbed) as the base path when issuing commands like 'find' (so, for example, if I was in /home/daniel/Build/some-project and the first stage of late was analyzing the project, qwen would do things like ls -F /home/tb or find /home/tb .... The workaround I have so far is a system prompt like:

This repository is in the directory /home/daniel/Build/some-project. Do not access files outside this repository.

With which qwen uses the correct directory when issuing commands. This was with late 1.0.2

This is not a late issue, just thought it worth mentioning.

EDIT: just noticed the ${{CWD}} variable a short while ago.

[danielfdickinson]

It's worth noting this is my first foray into using AI, so beginner mistakes are entirely likely.

[mlhher]

No worries feel free to open a discussion or issues for anything you might run into.
Everyone has to start somewhere.

--inject-cwd is enabled by default.

[aa956]

Agent got confused trying to edit file in the root of the project, actual location was like:

./src/SourceFile/SourceFile.c

Model sent the bash find command with -name containing literal double quotes, properly double escaped, as part of the file name:

"arguments": "{\"command\":\"find /home/user/src/project -name \\\"SourceFile.c\\\" 2>/dev/null\"}"

So nothing to fix here, I'll just add a project directory structure in agents.md (or add a find file mcp or tool working like find /path pattern(s) | head -n linecount as this gets called a lot in a projects I've tried late on).

Excerpt from llama-swap activity log (shortened instructions, changed paths/names):

{
  "model": "qwen3.6-35b-a3b",
  "messages": [
    {
      "role": "system",
      "content": "You are a **Coding Subagent** invoked --cut-- and what the issues are.\n"
    },
    {
      "role": "user",
      "content": "Goal: Fix the blue_byte assignment bug in SourceFile.c at line --cut-- This is a copy-paste error.\n\nIMPORTANT: Only change this one line. Do not modify any other code in the file.\n\n"
    },
    {
      "role": "user",
      "content": ""
    },
    {
      "role": "assistant",
      "content": "",
      "reasoning_content": "The user wants me to fix a bug in the SourceFile.c file at line 344. I need to change `green_byte` to `blue_byte` in the assignment. Let me first read the file to understand the context, then make the edit.\n",
      "tool_calls": [
        {
          "index": 0,
          "id": "eyYqCkNdGc1Y1eA2KJFlFZcGUcdizq4j",
          "type": "function",
          "function": {
            "name": "read_file",
            "arguments": "{\"path\":\"/home/user/src/project/SourceFile.c\",\"start_line\":336,\"end_line\":346}"
          }
        }
      ]
    },
    {
      "role": "tool",
      "content": "Error executing tool read_file: open /home/user/src/project/SourceFile.c: no such file or directory",
      "tool_call_id": "eyYqCkNdGc1Y1eA2KJFlFZcGUcdizq4j"
    },
    {
      "role": "assistant",
      "content": "",
      "reasoning_content": "The file doesn't exist at that path. Let me search for it.\n",
      "tool_calls": [
        {
          "index": 0,
          "id": "ODPe4oHHvYDPvCazfw9QPNLbKa1clL34",
          "type": "function",
          "function": {
            "name": "bash",
            "arguments": "{\"command\":\"find /home/user/src/project -name \\\"SourceFile.c\\\" 2>/dev/null\"}"
          }
        }
      ]
    },
    {
      "role": "tool",
      "content": "",
      "tool_call_id": "ODPe4oHHvYDPvCazfw9QPNLbKa1clL34"
    }
  ],
  "stream": true,
  "tools": "--cut--"
}

[aa956]

Tried find in the actual bash and it was not a problem with model or late or llama-swap or llama-server.

find returns empty when run:

• inside WSL virtual machine and
• search is performed inside directory symlinked to the directory from windows mount /mnt/c

Will investigate further but the failure is clearly in WSL, not late.