This is a very frustrating problem.
First of all, the errors are completely misleading: “We couldn’t detect the settings for your project! Please make sure you have a configuration file in place, and check our doc about manual build setup in CircleCI 2.0.” It suggests that the repo was cloned and it doesn’t have a config, or maybe that the old circle.yml has already been deprecated and only the 2.0 config works now as the version number in the error message may suggest, but meanwhile Circle doesn’t even know if there is any config or not, because it couldn’t clone the repo in the first place.
So the error should be: “We couldn’t access the fork repository! Please make sure that the repository referenced in the pull request exists and you have permissions to access it.”
Now, it is very strange to me that Circle uses its own unprivileged SSH key to access the fork by default for forks of private projects, which are almost always private.
First of all, it should use the same key as for non-fork PRs, but not expose it to the tests! Why do I have to give secrets to the CODE inside of the pull request, just to CLONE the repo in the pull request? Circle should use the key to clone the repo and not pass that key to the tests.
Second of all, if that fails, there should be an option (or maybe tried automatically) to clone the repo as a user that is the owner of the fork, if that uses has authorized Circle to do that before (maybe a setting per repository).
Note that both of those should be able to just clone the repo and forget the key, never giving it to the code that is being run by default, unless passing secrets is turned on.
It may have some problems (like not being able to install private dependencies in some cases) but would be better than trying to use an unauthorized key to clone a private repo and tell us that there are no tests on no configuration.
Currently the only option to fix that, not obvious at all, is what was suggested above, i.e. to turn on passing secrets to pull requests which even Circle rightly warns against: “There are serious security concerns with this setting (see the documentation for details.) If you have SSH keys, sensitive env vars or AWS credentials stored in your project settings and untrusted forks can make pull requests against your repo, then this option isn’t for you!”