Feature availability

Most of Syntic Code behaves identically no matter where it runs, because the intelligence lives in the Syntic model reached over the network. A handful of capabilities, though, depend on what the local environment provides. Knowing which features need which resources saves a lot of confusion when the agent behaves differently on a locked-down build agent than it does on a developer laptop.

What can vary by environment

Features that touch the local system are the ones most likely to differ. Running shell commands requires a shell and the tools those commands invoke, so a minimal container may lack utilities the agent expects. Editor and IDE integrations depend on a graphical or editor host being present, which build agents usually do not have. Anything that opens a browser, such as an interactive sign-in flow, needs a browser and a way to display it. And every network-dependent feature relies on the machine being able to reach api.syntic.ai or your gateway, which restrictive environments may block.

Checking what is available

Confirm the essentials on a representative machine before rolling out widely. Verify the binary runs, that it can authenticate, and that it can reach the model endpoint:

syntic --version
syntic doctor

The doctor check reports connectivity, credential status, and which optional capabilities are present, so it is the fastest way to see what a given environment supports.

Planning around gaps

When a feature is missing, decide whether to add the missing resource or to design around it. A CI runner that lacks a browser should use an API key or gateway credential instead of interactive sign-in. A container that runs shell-heavy tasks needs the relevant tools baked into its image. Where a feature simply cannot exist in an environment, restrict the tasks you send there rather than expecting the agent to compensate, and document the limitation so developers know what to expect on each target.