Skip to content

Potential file finding bug #89

Open
Open
Potential file finding bug#89
Labels
bugSomething isn't working

Description

@cristianknebel
cristianknebel
opened on Jun 27, 2026

Environment

  • SDK version: 0.1.5
  • Python version: 3.11
  • OS / platform: Windows 11 Home 64 bits
  • Install method: Through Pycharm package interface

Description

Hi, I have seen this kind of message when the agent was trying to access files from the path I have given it access to. The file exists at that path, but, for some reason the message still appears.
Message: WARNING:root:System step error (HTTP 0): The model produced an invalid tool call. ("model output error: invalid tool call error (invalid_args) failed to read file: open C:/Users/example/Desktop/Two words/Test-Path/Teacher - learner/joda-money/src/main/java/org/joda/money/CurrencyUnitRegistry.java: The system cannot find the file specified.")

Expected Behavior

I expected it to be able to find the file, because it exists at the specified path.

Actual Behavior

It was unable to find the existing file at the given path.

Activity

  1. cristianknebel
    added
    bugSomething isn't working
    on Jun 27, 2026

  2. Fon199800 commented on Jun 30, 2026

    @Fon199800
    Fon199800
    on Jun 30, 2026 via email

  3. Fon199800 commented on Jun 30, 2026

    @Fon199800
    Fon199800
    on Jun 30, 2026 via email

  4. THAC-ZERO commented on Jul 1, 2026

    @THAC-ZERO
    THAC-ZERO
    on Jul 1, 2026

    Hey there @cristianknebel , quick question -
    is that Desktop path by any chance OneDrive managed?

    On Win11 the desktop can be setup to be online-only which could be a cause here?
    Thanks in advance!

  5. cristianknebel commented on Jul 1, 2026

    @cristianknebel
    cristianknebel
    on Jul 1, 2026
    Author

    Hey there @cristianknebel , quick question - is that Desktop path by any chance OneDrive managed?

    On Win11 the desktop can be setup to be online-only which could be a cause here? Thanks in advance!

    Hello, thanks for the comment. I am not using OneDrive or any other similar tool. It is a local path, not managed by anything else.

  6. THAC-ZERO commented on Jul 1, 2026

    @THAC-ZERO
    THAC-ZERO
    on Jul 1, 2026

    Thanks @cristianknebel, so OneDrive is not it (not surpisingly).

    Two quick things to help pin it down:

    1. does it fail on that file every time or only sometimes? and

    2. could you set logging to DEBUG and grab the raw tool-call arguments for the read — the exact path string before it hits open()? The rendered error may be hiding a whitespace/escaping/encoding difference the raw args would show.

    3. Also handy: does python -c "print(open(r'<your path>').read())" from the same shell succeed?

    FWIW I couldn't reproduce on local (non-OneDrive) Win11 with a synthetic tree matching your path, so it seems specific to your setup.

  7. cristianknebel commented on Jul 3, 2026

    @cristianknebel
    cristianknebel
    on Jul 3, 2026
    Author

    Thanks @cristianknebel, so OneDrive is not it (not surpisingly).

    Two quick things to help pin it down:

    1. does it fail on that file every time or only sometimes? and
    2. could you set logging to DEBUG and grab the raw tool-call arguments for the read — the exact path string before it hits open()? The rendered error may be hiding a whitespace/escaping/encoding difference the raw args would show.
    3. Also handy: does python -c "print(open(r'<your path>').read())" from the same shell succeed?

    FWIW I couldn't reproduce on local (non-OneDrive) Win11 with a synthetic tree matching your path, so it seems specific to your setup.

    Thank you too for the advice. I ran the code with the changes you recommended. The behaviour happens for multiple files and when running the command, it actually was unable to find them. I also checked and there was no such file at the given path. I am even more confused now.

  8. Narjes0v0 commented on Jul 6, 2026

    @Narjes0v0
    Narjes0v0
    on Jul 6, 2026 · Hidden as resolved

  9. Fon199800 commented on Jul 7, 2026

    @Fon199800
    Fon199800
    on Jul 7, 2026 via email

  10. THAC-ZERO commented on Jul 8, 2026

    @THAC-ZERO
    THAC-ZERO
    on Jul 8, 2026

    Hmm... that's a helpful result. If the plain Python open() failed too and there's genuinely no file sitting at that path, then the path itself is the culprit — something's asking to read a file that isn't there. And since it's happening on multiple files, it feels systematic rather than a fluke.

    So I think the question flips a bit: it's less "why can't the tool find the file" and more "why is that path showing up at all when nothing's there."

    Two things that'd help figure out where the paths are coming from:

    • Are these paths you're passing in yourself, or ones the agent came up with on its own?
    • If it's the agent — does it list the folder first (list_dir / find_by_name) before the read, or does it jump straight to view_file on a path it never actually looked up? The DEBUG logs should show the order of tool calls.

    Thinking outloud here.... is it inventing reasonable-looking paths (the classic org/joda/money/... layout, say) instead of reading what's really on disk — but the tool-call order would tell us for sure. Happy to keep digging with you on it.

  11. cristianknebel commented on Jul 9, 2026

    @cristianknebel
    cristianknebel
    on Jul 9, 2026
    Author

    Hmm... that's a helpful result. If the plain Python open() failed too and there's genuinely no file sitting at that path, then the path itself is the culprit — something's asking to read a file that isn't there. And since it's happening on multiple files, it feels systematic rather than a fluke.

    So I think the question flips a bit: it's less "why can't the tool find the file" and more "why is that path showing up at all when nothing's there."

    Two things that'd help figure out where the paths are coming from:

    • Are these paths you're passing in yourself, or ones the agent came up with on its own?
    • If it's the agent — does it list the folder first (list_dir / find_by_name) before the read, or does it jump straight to view_file on a path it never actually looked up? The DEBUG logs should show the order of tool calls.

    Thinking outloud here.... is it inventing reasonable-looking paths (the classic org/joda/money/... layout, say) instead of reading what's really on disk — but the tool-call order would tell us for sure. Happy to keep digging with you on it.

    The path exists, it is just that the file does not exist. I am giving a base bath, where the project is, so the model knows where to look for files, edit them, etc. Then, I am letting it free in doing anything to every file that exists. Also to create files. Both the paths and file names are made by the model, not passed explicit by me (besides that base path where the project exists). I think I found some cases where it tried to use list_directory but still failed to find the file. Will upload some logs, think it is easier to take a look at them. Thank you, I am also glad to try and find a solution with you to this :)

    antigravity_debug.log
    antigravity_debug2.log
    antigravity_debug3.log

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions