Context
CANarchy's datasets provider catalog lists 14 real-world CAN datasets (ROAD, CANdid, commaCarSegments, HCRL Car-Hacking/J1939-Attack, SynCAN, etc.), positioned as part of the "agent-driven workflows" story in the README.
What happened
While trying to exercise the datasets_* MCP tools with real log data from an agent's perspective, every registered dataset's actual download host was unreachable from a standard sandboxed coding-agent network policy:
- ROAD →
zenodo.org — blocked
- CANdid →
figshare.com / ndownloader.figshare.com — blocked
- commaCarSegments →
huggingface.co — blocked
- HCRL datasets →
ocslab.hksecurity.net — blocked
Only git-hosting platforms (github.com, gitlab.com, bitbucket.org) and pypi.org/files.pythonhosted.org were reachable in that environment — which is a common, not unusual, default allowlist for sandboxed coding-agent environments. I ended up having to source a substitute dataset (SynCAN, which happens to be mirrored on GitHub) and hand-roll a converter to get any real data into CANarchy at all, which defeats the purpose of having a built-in dataset provider/converter pipeline.
Suggestion
Since CANarchy explicitly targets "agent-driven workflows," consider making at least a small representative slice of each registered dataset reachable from github.com — e.g. as GitHub Release assets on this repo, or a small bundled/cached fixture per provider (a few thousand frames, similar in spirit to the existing tests/fixtures/*.candump files but sourced from each real dataset). This would let datasets fetch + the analysis tools work end-to-end for agents running in network-restricted sandboxes, without requiring access to research-data hosts that are commonly blocked by default.
Context
CANarchy's
datasetsprovider catalog lists 14 real-world CAN datasets (ROAD, CANdid, commaCarSegments, HCRL Car-Hacking/J1939-Attack, SynCAN, etc.), positioned as part of the "agent-driven workflows" story in the README.What happened
While trying to exercise the
datasets_*MCP tools with real log data from an agent's perspective, every registered dataset's actual download host was unreachable from a standard sandboxed coding-agent network policy:zenodo.org— blockedfigshare.com/ndownloader.figshare.com— blockedhuggingface.co— blockedocslab.hksecurity.net— blockedOnly git-hosting platforms (
github.com,gitlab.com,bitbucket.org) andpypi.org/files.pythonhosted.orgwere reachable in that environment — which is a common, not unusual, default allowlist for sandboxed coding-agent environments. I ended up having to source a substitute dataset (SynCAN, which happens to be mirrored on GitHub) and hand-roll a converter to get any real data into CANarchy at all, which defeats the purpose of having a built-in dataset provider/converter pipeline.Suggestion
Since CANarchy explicitly targets "agent-driven workflows," consider making at least a small representative slice of each registered dataset reachable from github.com — e.g. as GitHub Release assets on this repo, or a small bundled/cached fixture per provider (a few thousand frames, similar in spirit to the existing
tests/fixtures/*.candumpfiles but sourced from each real dataset). This would letdatasets fetch+ the analysis tools work end-to-end for agents running in network-restricted sandboxes, without requiring access to research-data hosts that are commonly blocked by default.