Main thing: uqueryctx.inputs() gives you a file_set, which if you look in the docs, is just an iterable set of bxl.FileNode. These aren't artifacts, and you're just collecting their paths as strings and writing them into a file, so you can't expect Buck to track them. You need to turn them into source artifacts using ctx.fs.source(node) before you can use them as such.

More things:

1. Seems that BXL's actions.write does not really support with_inputs = True, even though it has the flag, it doesn't do anything.
2. BXL also doesn't seem to really implement allow_args = True, even though it has the flag and is documented. The returned list of input artifacts always seems to be empty.
3. Be aware that buck will print File changed: ... for literally any file that changes, including ones that are not referenced anywhere. Doesn't really mean anything.
4. This is a bit in the weeds, but generally I wouldn't write the list of files into the script itself. That means buck needs to write a new copy of the script each time the file list changes, i.e. every time you try to clang-tidy a different target. Probably just pass em as args to the script.
5. And since this is clang-tidy, you may want to do one actions.run per target, so you can configure clang-tidy with include paths from the target in question, for example. Perhaps this is what you have omitted for simplicity. But worth pointing out you probably want ctx.output.ensure_multiple if you're doing that.

I am running a bit of an old Buck2. Maybe those first two BXL issues have been fixed since.

All in all, this works:

def _cat_files_impls(ctx: BxlContext):
    actions = ctx.bxl_actions().actions

    # Each target expression expands to a list of targets, so we flatten the
    # input into a flat list of targets.
    targets = []
    for t in ctx.cli_args.targets:
        targets += t

    # The inputs() returns a file_set, which is a set of bxl.FileNode.
    # We need these as source artifacts.
    files = [ctx.fs.source(file) for file in ctx.uquery().inputs(targets)]

    report_file = actions.declare_output("all.txt")
    script = actions.write(
        "cat_files.sh",
        [
            "OUTPUT=\"$1\"",
            "shift",
            'cat "$@" > "$OUTPUT"',
        ],
        is_executable = True,
    )

    actions.run(
        cmd_args("/bin/sh", script, report_file.as_output(), files),
        category = "cat_files",
    )
    ensured = ctx.output.ensure(report_file)
    ctx.output.print(ensured)

# buck2 bxl cat_files.bxl:cat_files -- --targets thing//:main | xargs cat
cat_files = bxl_main(
    impl = _cat_files_impls,
    cli_args = {
        "targets": cli_args.list(cli_args.target_expr()),
    },
)

; buck2 bxl //thing/cat_files.bxl:cat_files -- --targets //thing:main | xargs cat
...
int main() { return 0; }
void thing() {}

; buck2 bxl //thing/cat_files.bxl:cat_files -- --targets //thing:main | xargs cat
File changed: root//thing/thing.c
...
BXL SUCCEEDED
int main() { return 0; }
void thing() {
        // yeah
}

Main thing: uqueryctx.inputs() gives you a file_set, which if you look in the docs, is just an iterable set of bxl.FileNode. These aren't artifacts, and you're just collecting their paths as strings and writing them into a file, so you can't expect Buck to track them. You need to turn them into source artifacts using ctx.fs.source(node) before you can use them as such.

Fantatic! I understood the root cause but had not found this ctx.fs.source API, thank you so much for pointing it out!

As to your other points:

1. I have not noticed this so far, all my inputs have always been materialized properly, but perhaps my use cases were just simple enough, or some other action had materialized it before hands.
2. Out of curiosity, what do you typically use allow_args for? I haven't had a use case for it (or at least I didn't realize that it would have been a convenient feature).
3. Of course, I just added that to "prove" that it wasn't something wrong with my inotify setup or something similar.
4. I suppose this answers my question for 2), doesn't it? :) This is a very good point, I hadn't considered that, thanks again for pointing that out.
5. Agreed, I just wanted to get something simple working first, but I do want to use ensure_multiple both for caching and parallelism.

For (2), it is used all over the prelude, like when putting together rustc argfiles. Those scripts are linked to a specific compile step, and only need rewriting when the dependency lists / rust flags change. That involves writing many flags conditionally, so it's useful for Buck to track which ones were actually used. I think it's just slightly less often useful in BXL, but you might do it for (5). The main benefit of getting dependencies written into the script itself is that you can open that file and see what buck is doing.