Toit
#jag run -D jag.wifi=false (not working)
Thread channel in help
crockedile 05/09/2025 04:04 PMUse live reloading over WiFI to turbo-charge developing for your ESP32. - toitlang/jaguar 
I'm running v2.0.0-alpha.179 and trying to run my code with the wifi connection disabled so I can put the esp32 into AP mode.
When attempting to run my code with these arguments - I get the error:
Error: unsupported Jaguar define: jag.wifi
I was simply following the documentation here:
https://github.com/toitlang/jaguar
When attempting to run my code with these arguments - I get the error:
Error: unsupported Jaguar define: jag.wifi
I was simply following the documentation here:
https://github.com/toitlang/jaguar
crockedile 05/09/2025 04:23 PM
I see - the github is out of date. The Toit website does have the proper argument:
jag run -D jag.disabled
jag run -D jag.disabled
OPcrockedileI see - the github is out of date. The Toit website does have the proper argument: jag run -D jag.disabled
bitphlipphar 05/09/2025 04:41 PM
1
Sorry about the confusion. We've updated the documentation before getting the release out 
1bitphlipphar 05/09/2025 04:41 PM1
It's typically the other way around 
1
Geoff 02/15/2026 09:34 PM
Having trouble disabling jag wifi also. Using v2.0.0-alpha.189. -D jag.disabled is now depreciated so I am back to -D jag.wifi=false -D jag.timeout=1m when installing container.
OUTPUT:
[jaguar] INFO: container 'flowi' installed and started with {jag.wifi: false, jag.timeout: 60}
INFO: PROV: Starting worker...
[wifi] DEBUG: connecting
[wifi] DEBUG: connected
[wifi] INFO: network address dynamically assigned through dhcp {ip: 192.168.0.133}
etc.
My program has no trouble connecting immediately, so wifi obviously not disabled, and after 1 minute my container is unceremoniously stopped as jag restarts its network (which I think was already running).
So what does -D jag.wifi=false actually do?
Thank you.
OUTPUT:
[jaguar] INFO: container 'flowi' installed and started with {jag.wifi: false, jag.timeout: 60}
INFO: PROV: Starting worker...
[wifi] DEBUG: connecting
[wifi] DEBUG: connected
[wifi] INFO: network address dynamically assigned through dhcp {ip: 192.168.0.133}
etc.
My program has no trouble connecting immediately, so wifi obviously not disabled, and after 1 minute my container is unceremoniously stopped as jag restarts its network (which I think was already running).
So what does -D jag.wifi=false actually do?
Thank you.
addshore 02/16/2026 12:50 PM
I think
So you can extend the default timeout
By default this runs with a 10 seconds timeout to avoid making the device inaccessible by Jaguar. You can configure the timeout by passing a separate -D jag.timeout option:
So you can extend the default timeout
addshore 02/16/2026 12:51 PM
you can also flash FW without jaguar entirely if you totally want to get rid of any of the wifi stuff it does
floitsch 02/16/2026 02:40 PM
As @addshore said.
The
Now with the
If you don't want to use Jaguar, consider creating your own envelope using
There is documentation on Toit's github repository, but the OTA tutorial also has a small section: https://docs.toit.io/tutorials/misc/ota/#preparing-the-new-firmware
The
timeoutjag.disabledNow with the
jag.wifi=falseIf you don't want to use Jaguar, consider creating your own envelope using
jag toit tools firmwaretoit tools firmwareThere is documentation on Toit's github repository, but the OTA tutorial also has a small section: https://docs.toit.io/tutorials/misc/ota/#preparing-the-new-firmware
Geoff 02/16/2026 08:32 PM
-D jag.timeout=1m apples both to your container's life and jaguar's -D jag.wifi=false ?
And maybe I have totally misunderstood Jaguar's role. I thought jaguar was a usually omnipresent wifi connection that provided OTA updates and serviced network requests from other containers/programs so other containers didn't have to reinvent the wheel. Maybe other containers do reinvent the connection and the only thing jaguar provides (behind the scenes) are the secure credentials it was loaded with (or updated with). But if another container's wifi connection is independant, why does a captiveAP need to disable jaguar?
Sorry to be dense, but I sure would like to understand.
And maybe I have totally misunderstood Jaguar's role. I thought jaguar was a usually omnipresent wifi connection that provided OTA updates and serviced network requests from other containers/programs so other containers didn't have to reinvent the wheel. Maybe other containers do reinvent the connection and the only thing jaguar provides (behind the scenes) are the secure credentials it was loaded with (or updated with). But if another container's wifi connection is independant, why does a captiveAP need to disable jaguar?
Sorry to be dense, but I sure would like to understand.
floitsch 02/16/2026 08:35 PM
The problem is that once a wifi connection is running you can't just start an AP. I don't even know if you can have both at the same time in Toit.
Jaguar is primarily a development tool (as there is no authentication...) and we expect final products to replace it with something else (for example Artemis). At home it's often convenient enough to just stick with it though. (I have done that too)
Jaguar is primarily a development tool (as there is no authentication...) and we expect final products to replace it with something else (for example Artemis). At home it's often convenient enough to just stick with it though. (I have done that too)
Geoff 02/16/2026 08:37 PM
So once jaguar (or any other container's network connection) is running it cannot be closed and an AP started?
floitsch 02/16/2026 08:38 PM
You can close it and start an AP, but Jaguar is (by default) always running. So your AP container doesn't work.
(Unless we fixed it and you can have both at the same time. Tbh I don't remember anymore).
(Unless we fixed it and you can have both at the same time. Tbh I don't remember anymore).
Geoff 02/16/2026 08:39 PM
Got it. Does artemis work the same way?
floitsch 02/16/2026 08:41 PM
Artemis only connects at regular intervals to check whether it needs to do a firmware update. So no.
But it is more complex and needs a server environment (although you can use ours for reasonable usage).
Since it only connects once in a while it is less convenient to develop with it. It's designed for deployed products that need an update from time to time
But it is more complex and needs a server environment (although you can use ours for reasonable usage).
Since it only connects once in a while it is less convenient to develop with it. It's designed for deployed products that need an update from time to time
Geoff 02/16/2026 08:44 PM
OK. So develop with jaguar, use -D jag.wifi=disabled to simulate Artemis typical unconnected state, then graduate to Artemis when code stable. I actually hope I'm close! Thank you for your help.
floitsch 02/16/2026 08:45 PM
That sounds right.
floitsch 02/16/2026 08:45 PM
For Artemis you also have the option to disallow connections from your own container.
Geoff 02/16/2026 08:47 PM
To prevent you from writing a program that connects to the internet? Why would you need that limitation?
floitsch 02/16/2026 08:48 PM
I mean, Artemis tries to connect at regular intervals. But if your AP is running it can't do that.
So Artemis has an API to tell it not to connect.
So Artemis has an API to tell it not to connect.
Geoff 02/16/2026 08:49 PM
I see. It facilitates an AP connection. But STA connections can coexist.
floitsch 02/16/2026 08:50 PM
Yes. Once a sta connection is established all containers reuse that one
Geoff 02/16/2026 08:51 PM
In a jaguar environment the jaguar sta connection is typically reused.
floitsch 02/16/2026 08:51 PM
Yes
Geoff 02/16/2026 08:52 PM
1
Again, thank you so much for helping me understand what I (and my AI) are doing!!
1floitsch 02/16/2026 08:53 PM
Happy to help
25 messages in total