<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#47388
I'll be doing some separate research on how agent options ends up as
`null` in the first place.
Obviously you can set `config:` in the agent options and hit `Save` and
the issue is reproduced but seems unlikely (one theory is GitOps doing
some overriding).
# Checklist for submitter
- [x] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
See [Changes
files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files)
for more information.
## Summary
`GetClientConfig` (`server/service/osquery.go`) panicked with
`assignment to entry in nil map` (returning 5XX on
`/api/v1/osquery/config`) when a host's resolved agent options had a
null `config`.
Root cause: `config` is initialized as an empty map, but
`json.Unmarshal([]byte("null"), &config)` silently sets the map to `nil`
(no error). When the host also had packs or scheduled queries, the later
`config["packs"] = ...` assignment panicked.
This adds a nil-guard that re-initializes the map after the unmarshal.
## Testing
- [x] Added/updated automated tests
Added `TestGetClientConfigNullConfig`, which sets `{"config":null}`
agent options plus a pack and asserts no panic/error and that `packs`
still serialize correctly.
- [x] QA'd all new/changed functionality manually
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Fixed a server crash that could occur when generating osquery
configuration for hosts with a null agent config.
* Improved config handling so hosts with packs and scheduled queries now
receive their configuration reliably, even when the base config is
empty.
* Added regression coverage to help prevent this issue from returning.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Lucas Manuel Rodriguez
ad0a39e067